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

From: Duzongpeng <[email-masked]>
Date: Wed, 16 Mar 2016 01:37:40 +0000

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 16 Mar 2016 08:16:58 +0000

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]] On Behalf Of Duzongpeng
Sent: 16 March 2016 02:38
To: [email-masked]
Cc: Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; Sheng Jiang <[email-masked]>
Subject: [Anima] Does Autonomic network need some intervention beyond intent

Hello, everyone

Best Regards
Zongpeng Du

---

From: Duzongpeng <[email-masked]>
Date: Wed, 16 Mar 2016 12:41:30 +0000

Hi, Michael,

         Thanks for the reply. I can understand that intent is not in the current milestones, and you are working on several milestones drafts now.

         You are welcome to contribute to the intent draft at any time, and thanks in advance.

         According to your statements, in my understanding, we can keep regarding the "intent" example in "prefix-management ID" as an Autonomic intent.
         It's semantics are just like "all nodes of type x do this; type y does that", so it is a high level policy.

         It really helps a lot. Thanks.

         I generally agree with your statement, while some other personal understandings exist (shown below). But perhaps they can be discussed later.

Best Regards
Zongpeng Du

From: Michael Behringer (mbehring) [mailto:[email-masked]]
Sent: Wednesday, March 16, 2016 4:17 PM
To: Duzongpeng; [email-masked]
Cc: Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
Subject: RE: [Anima] Does Autonomic network need some intervention beyond intent

Hi Zongpeng,

[duzongpeng] I agree that intent can coexist with traditional config.
I generally agree with the policy priorities, but I have some other concerns.
Some default policies/parameters set through "intent" perhaps are fundamental for the uplayer services.
It should be prevented that human operator uses some CLIs to change them by mistake, and the uplayer services are interrupted.
At least, some warning should be reported to the human operator. [duzongpeng]

[duzongpeng]Agree.[duzongpeng]

The downside is that there is no "control" an//d 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.

[duzongpeng]Agree. It is hard to give an exact boundary.
However, I think we have two choices here.
The first one is to define a policy first in every ASA, but with some open parameters that can be configured. What we need to do is just to distribute the network-level parameters for that function. This way is suitable to some relatively static functions.
The second is more advanced, in the ideal case, the human operator can communicate with network using natural language or something similar. This way is more flexible, but harder to realize.
[duzongpeng]

[duzongpeng]Agree.[duzongpeng]

Michael

From: Anima [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

Best Regards
Zongpeng Du

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Mar 2016 07:40:50 +1300

Yes, I think that whatever the "philosophy" of intent is, we should make sure that
the implementation is pragmatic and that we can adapt to operator's requirements.

Regards
   Brian

On 17/03/2016 01:41, Duzongpeng wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Duzongpeng <[email-masked]>
Date: Fri, 18 Mar 2016 08:33:25 +0000

Hi, Brian

	Thanks for the response. I think we have agreed that "prefix-management ID" can be an Autonomic intent.

	However, some ASA parameters may appear to be more static, and perhaps can fulfill the statement below: 

	Some examples can be 
	What kind of IGP the Autonomic network domain should use (such as IS-IS, OSPF); 
	What kind of transport layer network technology the Autonomic network domain should use (such as MPLS, IP)

	Should these ASA parameters be part of ANIMA's work items just as intent?

Best Regards
Zongpeng Du

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 2:41 AM
To: Duzongpeng; Michael Behringer (mbehring); [email-masked]
Cc: Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Yes, I think that whatever the "philosophy" of intent is, we should make sure that the implementation is pragmatic and that we can adapt to operator's requirements.

Regards
   Brian

On 17/03/2016 01:41, Duzongpeng wrote:
> Cc: Laurent Ciavaglia 
> <[email-masked]<mailto:[email-masked]>>; 
> Jéferson Campos Nobre 
> <[email-masked]<mailto:[email-masked]>>; Sheng Jiang 
> <[email-masked]<mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Mar 2016 08:16:58 +1300

Hi Zongpeng,

> Should these ASA parameters be part of ANIMA's work items just as intent?

As Michael's yang outline showed, there will be network-wide aspects to
intent and also ASA-specific aspects. I think that in practice there will
be simple parameters in the ASA-specific parts, so (whether we use yang or
some other syntax) I see no advantage in having a separate mechanism for
the parameters - in a sense we never need to answer the question, we simply
treat all the information in the same way, intent or parameter.

Maybe we should think about levels of specialization. Top level, network
intent. Next level, intent for all ASAs supporting a given objective.
Those two levels would be flooded by GRASP. Next level, intent for a single
ASA. That would be transmitted by unicast GRASP synchronization.

Regards
   Brian

---

From: Duzongpeng <[email-masked]>
Date: Mon, 21 Mar 2016 03:48:16 +0000

Hi, Brian

Thanks for your response. I agree with your idea.

According to recently discussion, I think perhaps we can give ANIMA intent a more general scope.

On one side, we should support the work of "Intent" defined in other work groups, which means the "intent" should be able to be inputted into the Autonomic network and work properly; 

On the other side, some parameters that are needed by Autonomic Network, even may not be considered as "intent" in other work groups, should also be included in the ANIMA intent scope, which may also need to be flooded by GRASP and ACP.

Of course, as said be Michael, we are still at preliminary stage, and the owner of an autonomic function should decide what is needed.
If things did not go rightly in the development of ASAs and modifications was proved to be needed, maybe we can work on version 2.

Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, March 21, 2016 3:17 AM
To: Duzongpeng; [email-masked]
Cc: Laurent Ciavaglia; Jéferson Campos Nobre; Michael Behringer (mbehring); Sheng Jiang
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Hi Zongpeng,

> Should these ASA parameters be part of ANIMA's work items just as intent?

As Michael's yang outline showed, there will be network-wide aspects to intent and also ASA-specific aspects. I think that in practice there will be simple parameters in the ASA-specific parts, so (whether we use yang or some other syntax) I see no advantage in having a separate mechanism for the parameters - in a sense we never need to answer the question, we simply treat all the information in the same way, intent or parameter.

Maybe we should think about levels of specialization. Top level, network intent. Next level, intent for all ASAs supporting a given objective.
Those two levels would be flooded by GRASP. Next level, intent for a single ASA. That would be transmitted by unicast GRASP synchronization.

Regards
   Brian

On 18/03/2016 21:33, Duzongpeng wrote:
> 	4. Rarely need coordinations with others parameters, usually is 
> closed related to one specific autonomic function
> 
> 	Some examples can be

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 21 Mar 2016 09:31:30 +0000

> Sent: 20 March 2016 20:17
> To: Duzongpeng <[email-masked]>; [email-masked]
> Cc: Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre
> <[email-masked]>; Sheng Jiang <[email-masked]>; Michael
> Behringer (mbehring) <[email-masked]>
> intent and also ASA-specific aspects. I think that in practice there will be
> simple parameters in the ASA-specific parts, so (whether we use yang or
> the parameters - in a sense we never need to answer the question, we
> simply treat all the information in the same way, intent or parameter.

Agree so far. 
 
> ASA. That would be transmitted by unicast GRASP synchronization.

Here I don't have the same view. The first two levels we agree on. Anything that's for a specific node doesn't qualify as "Intent" in my view. (Ignore that the flooding mechanism may contain unicast transmissions as part of the overall scheme). 

If Intent is a high-level policy (which I think we all agree on?) then I can think of two more "things" that are NOT Intent, to add to my list of "not-Intent": 

- anything that's for a specific node
- anything that's negotiated dynamically. (Intent is always originating from something non-technical - it's a policy).
- anything that needs to change frequently (high-level policy is normally pretty stable)
- anything that's not a "policy", ie doesn't come from a non-technical reasoning. (that's not a good way to define it, but can't think of a better one right now)

I think you're suggesting an optimisation of Intent *distribution*, Brian, right? Where, if I know only a few nodes run a certain function, I just send that particular Intent to those nodes only? (is that what you're thinking of?) 

This would certainly be tempting, but I think it's a slippery slope, and would quickly get into conflict with current policy models. I'd prefer if we keep "our" Intent as "must be flooded everywhere". If it is really high level guidance, the optimization shouldn't be needed. Said differently: If we start pushing huge data models, maybe we're on the wrong track in the first place? 

Michael

> > 	Thanks for the response. I think we have agreed that "prefix-
> management ID" can be an Autonomic intent.
> >
> > 	What kind of transport layer network technology the Autonomic
> network
> > domain should use (such as MPLS, IP)
> >
> > Yes, I think that whatever the "philosophy" of intent is, we should make
> sure that the implementation is pragmatic and that we can adapt to
> operator's requirements.
> >
> > Regards
> >    Brian
> >
> >>          Thanks for the reply. I can understand that intent is not in the current
> milestones, and you are working on several milestones drafts now.
> >>
> >>          According to your statements, in my understanding, we can keep
> regarding the "intent" example in "prefix-management ID" as an Autonomic
> intent.
> >>          I generally agree with your statement, while some other personal
> understandings exist (shown below). But perhaps they can be discussed
> later.
> >>
> >> Best Regards
> >> Zongpeng Du
> >>
> >> 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.
> >>
> >> It should be prevented that human operator uses some CLIs to change
> them by mistake, and the uplayer services are interrupted.
> >> 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.
> >>
> >> The downside is that there is no "control" an//d 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.
> >>
> >> The first one is to define a policy first in every ASA, but with some open
> parameters that can be configured. What we need to do is just to distribute
> the network-level parameters for that function. This way is suitable to some
> relatively static functions.
> >> The second is more advanced, in the ideal case, the human operator can
> communicate with network using natural language or something similar. This
> way is more flexible, but harder to realize.
> >> [duzongpeng]
> >>
> >> 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
> >>
> >>
> >>
> >> 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.
> >>
> >> 4.       Rarely need coordinations with others parameters, usually is closed
> related to one specific autonomic function
> >>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 21 Mar 2016 09:46:41 +0000

Hi Brian and all,

> Those two levels would be flooded by GRASP. 

[Bing] For "ASAs supporting a given objective", flooding surely would work. But I'm wondering whether we also need a selective flooding mechanism to cut some unnecessary signaling amplification.
When one node receive the intent, it only replicates the intent to the neighbors that fit for some conditions. This node behavior implies some assumption:
1) The intent content includes the "conditions" (e.g., flood to a specific tunnel; or flood to a certain set of rules etc.)
2) The nodes know about their neighbors' info to identify whether the neighbors fit the conditions.

Do you consider this as a complementary mechanism to normal flooding?

Best regards,
Bing

> Next level, intent for a single
> > 	Thanks for the response. I think we have agreed that
> "prefix-management ID" can be an Autonomic intent.
> >
> >>          Thanks for the reply. I can understand that intent is not in the
> current milestones, and you are working on several milestones drafts now.
> >>
> >>          According to your statements, in my understanding, we can
> keep regarding the "intent" example in "prefix-management ID" as an
> Autonomic intent.
> >>          It's semantics are just like "all nodes of type x do this; type y
> does that", so it is a high level policy.
> >>
> >>          I generally agree with your statement, while some other
> personal understandings exist (shown below). But perhaps they can be
> discussed later.
> >>
> >> Best Regards
> >> Zongpeng Du
> >>
> 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.
> >>
> what I describe above COULD be abused in this way. RFC7575 says this is
> NOT Intent.
> >>
> >>          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.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 21 Mar 2016 12:33:13 +0100

Hello,

Please see below for my comments.

>> simply treat all the information in the same way, intent or parameter.
If we refer to so-called policy-continuum, a policy is defined and 
refined from a high-level/abstract point, usually with network-wide 
considerations, down to low-level device parameters.
This is thus completely part of the policy based management approach.
What we need in ANIMA is to define (re-use), and agree on the levels of 
the hierarchy and how we call (again re-use terms) the levels and 
elements in each level.

>> ASA. That would be transmitted by unicast GRASP synchronization.
Comment to Brian's point: usually we write (multiple) policies based on 
the needs/objectives of the network operations. It is the 
resolution/processing of the policies that determine the set of target 
entities.

> - anything that's for a specific node
Agree, but we should be careful in the interpretation:
     -By nature, a policy targets a group of entities/role/function.
     -It is the evaluation/resolution of the policies that determines 
the set of target entities. This set may contain only a single 
"node"/entity.

> - anything that's negotiated dynamically. (Intent is always originating from something non-technical - it's a policy).
I don't really understand what you mean by "negotiating" and 
"dynamically"...
Which are the entities negotiating?
What is dynamic important? (how do you negotiate something statically?)

With "non-technical" do you have in mind something like business-level 
policy?
How would you qualify a policy written as "secure all communications"? 
or "maximize link usage"...?

--> my guess is that we need to define more than the "ANIMA" 
intent-policy, and include at least the "levels" in the hierarchy to 
understand better where the intent-policy starts and stops (and then is 
translated into something else)

> - anything that needs to change frequently (high-level policy is normally pretty stable)
I would tend to agree, but would slightly change the angle, because with 
your definition the issue is how to set the cursor on frequency.
A policy is a statement or goal is not time dependent. As long as the 
policy is "active", it should be evaluated (here time/context might come 
into consideration).
Whether the policy is activated/deactivated, changed, erased... is not 
dependent on the system, but on the user.

> - anything that's not a "policy", ie doesn't come from a non-technical reasoning. (that's not a good way to define it, but can't think of a better one right now)
Let's try to dig in...
If I guess right, one example would be ASAs converging on the settings 
of common parameters...?
Again, if we define a hierarchy this will clear out what is a policy and 
where it starts/ends, and the other things we manipulate.
However, one note in the context of ANIMA / autonomic networking: we 
consider an approach where ASAs exchange "policy" among each others in a 
peer-to-peer manner... Maybe we have to clarify if this is indeed policy 
or something else.

> This would certainly be tempting, but I think it's a slippery slope, and would quickly get into conflict with current policy models. I'd prefer if we keep "our" Intent as "must be flooded everywher…
I have mixed feeling over this one.
I can buy the "flood everywhere" for the simplicity (but how important 
is it compared to other criteria...?).
I see at least two issues:
     1. flooding a "big" intent file (cf your current tentative example) 
may be bandwidth hungry, if one considers how frequently such an intent 
file could be distributed (ASA stop/start, device join/leave, policy 
change/update...)
      - compared to distributing only what is required / where it is 
required.
     2. security: flooding the entire file reveal information to target 
(possibly undesirable/rogue) entities that do not need it (and thus may 
mis-use it).

I think the first step would be again to agree on our definitions, scope 
and hierarchy.

Best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

Route de Villejust | 91620 Nozay | France

LinkedIn: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Mar 2016 08:52:54 -0400

The ANIMA bootstrap work is coming along.  The question of how, prior to
secure bootstrap, the New Node (the pledge) finds the proxy has been resolved
with the use of dnssd/mDNS-service-discovery on the link local addresses.
This has been selected on the basis of code reuse for devices which need/want
to bootstrap, but which might never participate in the ACP itself.  Please
see our draft.

There remains two other things that need to discover which we do not cover,
which are more ANIMA general problems.  These are:
  1) the "discovery" ("revelation"?) of a node that it needs to become
     a proxy.

  2) the discovery of the proxy node of the registrar.

These are things that *could* be determined by "power-on-above", i.e. a
controller in the NOC could push (netconf-style or otherweise) configuration
into a node to tell it, "You will be a bootstrap proxy on interfaces A,C and
Q, and the registrar is at address BAR"

Or these things could be discovered via ASA.

number (2) -- discoverying the registrar by the proxy node should be a
       relatively straight forward application of GRASP over the secured
       ACP to discover an ASA.

number (1) -- whether to become a proxy on a particular interface ought also
       to be negotiated via the secured ACP, even though the proxy could
       observe the mDNS-service-discovery process, the node which replies
       could in fact be malicious.
       So this is a less straightforward application of GRASP, it needs to
       driven by an intent that says something like: "new nodes may join
       network BAR on interface FOO"  for suitable abstractions of "FOO"
       being device independant.

There is also the ASA which would cause a node to turn itself into a
registrar (or rather, enable a registrar container, process or VM) when it
realizes that there is no other registrar, but I think that this is a higher
level of independance of Autonomic than we are ready for yet.

Aside from socializing these requirements into the larger group, I think that
we also looking for someone who might step forward to take the lead on these
two documents.  Maybe someone new?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 08:13:28 +1300

On 21/03/2016 22:31, Michael Behringer (mbehring) wrote:

...
> Here I don't have the same view. The first two levels we agree on. Anything that's for a specific node doesn't qualify as "Intent" in my view. (Ignore that the flooding mechanism may contain unicas…

Yes, OK, I like Laurent's formulation of a continuum - with intent at one end
and traditional configuration of a single parameter in a single ode at the other
end.

> I think you're suggesting an optimisation of Intent *distribution*, Brian, right? Where, if I know only a few nodes run a certain function, I just send that particular Intent to those nodes only? (…

Yes, but only when we are a long way down the continuum, so maybe that would be a
more traditional "policy" rather than "intent".

> This would certainly be tempting, but I think it's a slippery slope, and would quickly get into conflict with current policy models. I'd prefer if we keep "our" Intent as "must be flooded everywher…

I agree with that.

> Do you consider this as a complementary mechanism to normal flooding?

I think it's quite complicated, because it is essentially a special-purpose
multicast mechanism, where group membership is defined at application level
(for example, all nodes interested in objective "X"). At the moment we have
a two level mechanism (all GRASP nodes = flooding, one GRASP node = synchronization).

As Michael suggested, if the total intent data model is not too big, we can
simply flood it everywhere and nodes will select the relevant items.

    Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 21 Mar 2016 22:39:11 +0100

> and traditional configuration of a single parameter in a single ode at the other

The credits go to Bob Natale: 
https://mailarchive.ietf.org/arch/msg/anima/QL-FKVtU-XjCCdWg6C-qDJ8WWyw

Best regards, Laurent.

---

From: John Strassner <[email-masked]>
Date: Mon, 21 Mar 2016 15:50:37 -0700

I understand that Autonomic network should be able to work with as
less configuration as possible.

<jcs>
Why is this? The only reason I could imagine for this is if the components
of the autonomic network were each significantly more intelligent than
current components, and hence, could reason about what needed to
change in their configuration. However, this doesn't necessarily mean
that the **internal** configuration is less complicated. Rather, it implies
that there should be less communication about configuration changes.
Right?
</jcs>

In the ideal case, an Autonomic network should be able to work well
while only intent is needed from human operators.

<jcs>
This depends on what you mean by intent. With all due respect, we
first need to tighten the definition of intent rather than speculate what
to do with something we don't all agree about.
</jcs>

         However, I wonder whether Autonomic network may need
some intervention from human operators through some low-level
policies beyond intents.

<jcs>
I think that this is implementation-specific. For example, in OpenStack
Congress, we use an extended version of datalog. There is no reason
in general to use anything else.

That being said, I want to agree, but would like to understand your
reasoning in more detail before I say "yes".
</jcs>

         For example, in the
 https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00
<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.

<jcs>
I am missing what is intent here. This is just a simple mapping of
a role to something. We could do the exact same thing without
using intent.

In fact, I'm a bit worried that this is not a good application of
intent. How many users will know what a prefix is? :-) At least in
the ONF and the TMF, we have decided that intent really belongs
in the higher layers (at the user, business person, and app
developer layers), and not on the device.
</jcs>

         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.

<jcs>
I think that this would be a good idea...
</jcs>

Is “ASA parameters" ok here?

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

<jcs>
If we want to talk about translating intent, we should
probably look at putting this in either the anima
reference model (or better, mention it there and then
point to a separate draft), or start a new draft.
Note that we have had discussions in SUPA, as well
as in the ONF and TMF, about such a function.

If there is sufficient interest, I could write up an I-D.
</jcs>

regards,
John

On Tue, Mar 15, 2016 at 6:37 PM, Duzongpeng <[email-masked]> wrote:

> 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
> 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
> Perhaps we can rename the “intent” in the “prefix-management ID” to some
> other words.
>
>
>
> Is “ASA parameters" ok here?
>
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 16:36:20 +1300

A few questions and comments:

>   2) the discovery of the proxy node of the registrar.

Does that mean that there is exactly one registrar per AN?

> Q, and the registrar is at address BAR"

That doesn't really seem right, because it assumes that the NOC has
perfect knowledge of the topology. Potentially, any node with multiple
link interfaces could be a proxy, and if the topology is non-redundant,
they would all need to be proxies.

>        relatively straight forward application of GRASP over the secured

Quite easy. A few Python statements, including having the proxy
register itself with GRASP:

ok, asa_nonce = grasp.register_asa("AN_Proxy")
if not ok:
    exit() #Oops, another proxy is already registered
obj = grasp.objective("AN_Registrar")
obj.loop_count = 4
obj.synch = True
registrar_locators = grasp.discover(asa_nonce, obj, 5000)
if registrar_locators == []:
    exit() #Oops, there is no registrar

>        being device independant.

ACP nodes that are connected to multiple links will know that fact about
themselves, so they know they are potential proxies. Indeed, they could
always start up an ASA which is a *candidate* proxy and it would then
decode the network intent to figure out what to do next.

> level of independance of Autonomic than we are ready for yet.

Maybe, but is it all that scary? All the potential registrars could discover
each other and go through an election process. In fact it could even be
an intent option: elect_registrar = true.

   Brian

---

From: John Strassner <[email-masked]>
Date: Tue, 22 Mar 2016 13:32:27 -0700

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” J

<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]> wrote:

> 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” J  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
> (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.
>
>
>
> 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.
>
>
>
> 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]] *On Behalf Of *Duzongpeng
> *Sent:* 16 March 2016 02:38
> *To:* [email-masked]
> *Cc:* Laurent Ciavaglia <[email-masked]>; Jéferson Campos
> Nobre <[email-masked]>; Sheng Jiang <[email-masked]>
> *Subject:* [Anima] Does Autonomic network need some intervention beyond
> intent
>
>
>
> Hello, everyone
>
>
>

-- 
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 23 Mar 2016 12:54:43 +0100

Michael,

There are some aspects I am not sure to fully understand / agree with 
(marked below with [LC]).

Best regards, Laurent.

On 23/03/2016 11:57, EXT Michael Behringer (mbehring) wrote:
>
> John,
>
> /[stripped]/
>
> 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.
>

[LC]
Before stating that intent policies should be flooded to all nodes, can 
we first compare/evaluate the different options?
-broadcast is simple...but how important is it compared to other 
criteria...?
I see at least two issues:
1. flooding a "big" intent file (cf your current tentative example) may 
be bandwidth hungry, if one considers how frequently such an intent file 
could be distributed (ASA stop/start, device join/leave, policy 
change/update...) compared to distributing only what is required / where 
it is required.
2. security: flooding the entire file reveal information to target 
(possibly undesirable/rogue) entities that do not need it (and thus may 
mis-use it).

More fundamentally, I think it is misleading to imagine that intent 
policies will be contained in one "file" (it is possible to do so but 
impractical/cumbersome to manage). cf also the next comment.
[/LC]

> My suggestion: Intent is flooded to all nodes in a domain.
>
[LC]
It is the "resolution" of the intent clauses that determines the 
domain/set of target "nodes".
So in that order, yes the intent will be flooded to all the relevant 
nodes in the "intent policy domain". This domain may be all nodes in an 
ANIMA network, or a sub-set, only one node, or zero. This is contextual.
There will be _*many*_ intent policies for a given ANIMA network.
[/LC]

> 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 J
>
[LC]
I think we have a disconnect on what an intent look like and how it can 
be used.
In my "mental model", there is not one "big" intent with sub-parts for 
each ASA, the ANI, etc...
Each ASA designer (owner) will define the content / specificity of its 
ASA functionality or links to the existing elements of the ANIMA intent 
policy model, but it does not mean that we must aggregate all parts into 
a single "file".
What would be the reason to do that?

In addition, there will not only be intent policies per functions, or 
for the ANI.
There will be intent policies conveying the Service level, the Business 
level... these will not resolve/map 1-to-1 in a single ASA "policy".
[/LC]

> 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?!?
>
[LC]
It is OK to have different intent-policies for the fabric and for the 
functions, but why put them all into one file/policy?
[/LC]
>
> “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.
>
[LC]
I fully agree on the focus per autonomic function, but it does not imply 
to have one single intent policy with all parts inside.
[/LC]

> We should schedule some discussion time outside the ANIMA meeting 
> window...
>
[LC]
Yes. And a white board too!
Unfortunately, I cannot attend physically this time.
Can we schedule a face-to-face ad-hoc meeting?
[/LC]

> Michael
>
> *From:*John Strassner [mailto:[email-masked]]
> *Sent:* 22 March 2016 21:32
> *To:* Michael Behringer (mbehring) <[email-masked]>; John 
> Strassner <[email-masked]>
> *Cc:* Duzongpeng <[email-masked]>; [email-masked]; Laurent 
> Ciavaglia <[email-masked]>; Jéferson Campos Nobre 
> <[email-masked]>; Sheng Jiang <[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>
>
> 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” J
>
> <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>
>
> 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>
>
> 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>
>
> want, in the worst case even push config, which is clearly NOT what 
> Intent is meant to do.
>
> <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,
>
>     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”
>     J  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.
>
>     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
>     *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.
>
>     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,
>     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
>     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
>     [email-masked] <mailto:[email-masked]>

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 23 Mar 2016 10:57:02 +0000

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>

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]]
Sent: 22 March 2016 21:32
To: Michael Behringer (mbehring) <[email-masked]>; John Strassner <[email-masked]>
Cc: Duzongpeng <[email-masked]>; [email-masked]; Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; Sheng Jiang <[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>

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>

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>

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>

<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>

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,

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.

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

Hello, everyone

         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.

Best Regards
Zongpeng Du

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 23 Mar 2016 12:58:25 +0000

Laurent,
I actually agree with most of your points! ☺  There are many ways to address the problem, and more flexibility may (!) be good. It is easy to make Intent more complex. Before we do that though, I’d like to understand why a very simple model won’t do.
My feeling is that all of us have different view on what “Intent” actually is, and that is the actual disagreement.
To me, Intent describes a high level default behaviour of a network. This isn’t going to change often, otherwise it’s not “high level”. And it’s small too, otherwise again it’s not “high level”.
Maybe we need to look at a few use cases again, and see whether our views converge...
Michael
From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 23 March 2016 12:55
To: Michael Behringer (mbehring) <[email-masked]>; John Strassner <[email-masked]>
Cc: Duzongpeng <[email-masked]>; [email-masked]; Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; Sheng Jiang <[email-masked]>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Michael,

There are some aspects I am not sure to fully understand / agree with (marked below with [LC]).

Best regards, Laurent.

[stripped]

[LC]
Before stating that intent policies should be flooded to all nodes, can we first compare/evaluate the different options?
-broadcast is simple...but how important is it compared to other criteria...?
I see at least two issues:
1. flooding a "big" intent file (cf your current tentative example) may be bandwidth hungry, if one considers how frequently such an intent file could be distributed (ASA stop/start, device join/leave, policy change/update...) compared to distributing only what is required / where it is required.
2. security: flooding the entire file reveal information to target (possibly undesirable/rogue) entities that do not need it (and thus may mis-use it).

More fundamentally, I think it is misleading to imagine that intent policies will be contained in one "file" (it is possible to do so but impractical/cumbersome to manage). cf also the next comment.
[/LC]

My suggestion: Intent is flooded to all nodes in a domain.
[LC]
It is the "resolution" of the intent clauses that determines the domain/set of target "nodes".
So in that order, yes the intent will be flooded to all the relevant nodes in the "intent policy domain". This domain may be all nodes in an ANIMA network, or a sub-set, only one node, or zero. This is contextual.
There will be many intent policies for a given ANIMA network.
[/LC]

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 ☺
[LC]
I think we have a disconnect on what an intent look like and how it can be used.
In my "mental model", there is not one "big" intent with sub-parts for each ASA, the ANI, etc...
Each ASA designer (owner) will define the content / specificity of its ASA functionality or links to the existing elements of the ANIMA intent policy model, but it does not mean that we must aggregate all parts into a single "file".
What would be the reason to do that?

In addition, there will not only be intent policies per functions, or for the ANI.
There will be intent policies conveying the Service level, the Business level... these will not resolve/map 1-to-1 in a single ASA "policy".
[/LC]

<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?!?
[LC]
It is OK to have different intent-policies for the fabric and for the functions, but why put them all into one file/policy?
[/LC]

“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.
[LC]
I fully agree on the focus per autonomic function, but it does not imply to have one single intent policy with all parts inside.
[/LC]

[LC]

Michael

From: John Strassner [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

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--

Laurent Ciavaglia
Senior Research Manager
Bell Labs, Nokia

+33 160 402 636
Route de Villejust | 91620 Nozay | France
LinkedIn: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 23 Mar 2016 17:56:55 +0000

I really like your suggestion of flooding intent to all nodes (even if there may be optimizations later).  It provides a level of conceptual clarity.  Every node should be aware of overall intent (and need to decide for itself if there are actions for it to take).

If there is some intent that applies only to some parts of the network and not others, that can be addressed by using different Autonomic Domains.  And, of course, Autonomic Domains may be associated with certain Autonomic Functions.  Intervention beyond intent should NOT be allowed for the Autonomic Function(s) being served an Autonomic Domain, but of course other interventions (for different functions, hence outside the scope) are still possible.

--- Alex

From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Wednesday, March 23, 2016 3:57 AM
To: John Strassner <[email-masked]>
Cc: Duzongpeng <[email-masked]>; Laurent Ciavaglia <[email-masked]>; Sheng Jiang <[email-masked]>; [email-masked]; Jéferson Campos Nobre <[email-masked]>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

John,

<jcs>

Michael

From: John Strassner [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

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Mar 2016 14:43:38 -0400

I think the quesiton is what the scope of an intent is.
If, as seems likely, a given intent is for processing by a given objective,
and given that the objectives each form a connected graph over the domain,
it would seem sensible to flood the intent to the participants in the 
objective.

If intents are not mapped (by the time they get into ANIMA) to a single 
objective, then it probably makes more sense to flood more generally.

To some degree this also depend on how often we expect intents to be 
introduced, modified, or deleted.  If that rate is low, then flooding 
everywhere is probably cheap.  If that rate is high, I would want to be 
able to constrain the propagation.

Yours,
Joel

On 3/23/16 1:56 PM, Alexander Clemm (alex) wrote:
> I really like your suggestion of flooding intent to all nodes (even if
> there may be optimizations later).  It provides a level of conceptual
> clarity.  Every node should be aware of overall intent (and need to
> decide for itself if there are actions for it to take).
>
> If there is some intent that applies only to some parts of the network
> and not others, that can be addressed by using different Autonomic
> Domains.  And, of course, Autonomic Domains may be associated with
> certain Autonomic Functions.  Intervention beyond intent should NOT be
> allowed for the Autonomic Function(s) being served an Autonomic Domain,
> but of course other interventions (for different functions, hence
> outside the scope) are still possible.
>
> --- Alex
>
> *From:*Anima [mailto:[email-masked]] *On Behalf Of *Michael
> Behringer (mbehring)
> *Sent:* Wednesday, March 23, 2016 3:57 AM
> *To:* John Strassner <[email-masked]>
> *Cc:* Duzongpeng <[email-masked]>; Laurent Ciavaglia
> <[email-masked]>; Sheng Jiang <[email-masked]>;
> [email-masked]; Jéferson Campos Nobre <[email-masked]>
> 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 J
>
> <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?!?
>
> Probably we need to discuss that in BA. But refer to my YANG model sent
> a few days ago.
>
> *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]>>
> 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>
>
> actors that are using intent. For example, most of my CCIE and JCIE
> more “parameters” than “policy”, and I think we’ll just have to
> acknowledge that.
>
> <jcs>
>
> 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>
>
> locally, and if so, it’ll just pass that piece of Intent to that function.
>
> <jcs>
>
> Agreed.
>
> </jcs>
>
>     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.
>
>     keep it very high level, more along the line “do the right thing” J
>     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.
>
>     with as less configuration as possible. In the ideal case, an

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 23 Mar 2016 19:11:15 +0000

One question is how you would form a connected graph of objectives and how that would be resolved?  Isn't it simpler to simply assert for a given Autonomic Domain, what its intent is?  If you choose to form multiple Autonomic Domains, then so be it, but if you find yourself fine tuning / optimizing things too much, perhaps that is also an indication that you are going from intent to something that is lower level.  Likewise for intent change rate.  If that rate becomes too rapid, it may be an indication as well that you go from intent and "managing by objectives" into traditional configuration and "micromanagement".  
--- Alex

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2016 11:44 AM
To: Alexander Clemm (alex) <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; John Strassner <[email-masked]>
Cc: Duzongpeng <[email-masked]>; Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; [email-masked]; Sheng Jiang <[email-masked]>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

I think the quesiton is what the scope of an intent is.
If, as seems likely, a given intent is for processing by a given objective, and given that the objectives each form a connected graph over the domain, it would seem sensible to flood the intent to the participants in the objective.

If intents are not mapped (by the time they get into ANIMA) to a single objective, then it probably makes more sense to flood more generally.

To some degree this also depend on how often we expect intents to be introduced, modified, or deleted.  If that rate is low, then flooding everywhere is probably cheap.  If that rate is high, I would want to be able to constrain the propagation.

Yours,
Joel

On 3/23/16 1:56 PM, Alexander Clemm (alex) wrote:
> allowed for the Autonomic Function(s) being served an Autonomic 
> Domain, but of course other interventions (for different functions, 
> hence outside the scope) are still possible.
>
> --- Alex
>
> 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 
> 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 
> 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 
> 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 J
>
> <jcs>
>
> "Function owner": Yes, I'm suggesting to structure Intent around 
> *Cc:* Duzongpeng <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Laurent Ciavaglia 
> First, ANIMA isn't the only thing "influencing" or "steering" a 
> that ANIMA sets a "default" policy in a network, and all other means 
> RFC7575. Main point here: ANIMA Intent isn't the only tool in a network.
>
> <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" J
>
> <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>
>
> Personally I think it'll pan out like this: Intent will have sections 
> locally, and if so, it'll just pass that piece of Intent to that function.
>
> <jcs>
>
> Agreed.
>
> </jcs>
>
> The downside is that there is no "control" and people can do what they 
> 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 
>     First, ANIMA isn't the only thing "influencing" or "steering" a
>     been that ANIMA sets a "default" policy in a network, and all other
>     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
>     keep it very high level, more along the line "do the right thing" J
>     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
>     locally, and if so, it'll just pass that piece of Intent to that
>     function.
>
>     The downside is that there is no "control" and people can do what
>     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
>     contribute, I'm just struggling with priorities at the moment (as
>     enterprise network. Perhaps we can rename the "intent" in the
>     "prefix-management ID" to some other words.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Mar 2016 16:05:10 -0400

As I read it, GRASP already forms that connected network of ASAs which 
support a given objective.  Maybe I missed something in the design of 
the discovery mechanism, but I thought that was the point of it.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2016 13:38:23 +1300

On 24/03/2016 09:05, Joel M. Halpern wrote:
> As I read it, GRASP already forms that connected network of ASAs which support a given objective.  Maybe I missed something in
> the design of the discovery mechanism, but I thought that was the point of it.

True, but the knowledge is distributed across multiple discovery caches. We'd have to add
a protocol feature to provide the equivalent of pub/sub, but I don't think it would
be hard to do. (There's a model sketched in draft-liu-anima-grasp-distribution,
which I haven't thought about much yet.)

   Brian

>> One question is how you would form a connected graph of objectives and how that would be resolved?  Isn't it simpler to simply
>> assert for a given Autonomic Domain, what its intent is?  If you choose to form multiple Autonomic Domains, then so be it, but
>> if you find yourself fine tuning / optimizing things too much, perhaps that is also an indication that you are going from
>> intent to something that is lower level.  Likewise for intent change rate.  If that rate becomes too rapid, it may be an
>> indication as well that you go from intent and "managing by objectives" into traditional configuration and "micromanagement".
>> --- Alex
>>
>> Cc: Duzongpeng <[email-masked]>; Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre
>> <[email-masked]>; [email-masked]; Sheng Jiang <[email-masked]>
>> If, as seems likely, a given intent is for processing by a given objective, and given that the objectives each form a
>> connected graph over the domain, it would seem sensible to flood the intent to the participants in the objective.
>>
>> To some degree this also depend on how often we expect intents to be introduced, modified, or deleted.  If that rate is low,
>> then flooding everywhere is probably cheap.  If that rate is high, I would want to be able to constrain the propagation.
>>
>> Yours,
>> Joel
>>

---

From: John Strassner <[email-masked]>
Date: Wed, 23 Mar 2016 19:41:29 -0700

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 J
<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]> wrote:

> 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.
>
>
>
> 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 J
>
>
>
> <jcs>
>
> “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.
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *To:* Michael Behringer (mbehring) <[email-masked]>; John Strassner <
> [email-masked]>
> Ciavaglia <[email-masked]>; Jéferson Campos Nobre <
> [email-masked]>; Sheng Jiang <[email-masked]>
> 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
>
>
>
>
>
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2016 16:03:52 +1300

> they would all need to be proxies.

This has been niggling at me.

1. Does it matter if there is more than one proxy on a given LAN?

2. If it does matter, the algorithm seems to be something like:

   1. Do I have more than one LAN interface?
      If no, I cannot be a proxy; exit
   2. Is there an active proxy on any interface?
      If yes, exclude that interface for now.
   3. Can I discover the registrar via any interface?
      If no, I cannot be a proxy; exit
   4. Register myself as a proxy on the non-excluded interfaces.

I don't think we need any input from a higher power. We just need
the registrar to register itself with GRASP (so that it can
be discovered) and the proxy instance in each node to execute the
above algorithm once in a while.

Regards
   Brian

---

From: John Strassner <[email-masked]>
Date: Wed, 23 Mar 2016 20:22:33 -0700

Hi Laurent,

Thanks for your note. I'd be happy to join in a virtual meeting. Please see
<jcs>..</jcs> for my observations.

John,

*[stripped]*
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.
[LC]
Before stating that intent policies should be flooded to all nodes, can we
first compare/evaluate the different options?
-broadcast is simple...but how important is it compared to other
criteria...?
I see at least two issues:
1. flooding a "big" intent file (cf your current tentative example) may be
bandwidth hungry, if one considers how frequently such an intent file could
be distributed (ASA stop/start, device join/leave, policy change/update...)
compared to distributing only what is required / where it is required.

<jcs>
Hopefully, intent will not change frequently (or else it probably is too
low level in nature). I personally like using pub-sub, but that is because
it enables me to do additional pre- and post-processing of intent. However,
I think that this should be an option.
< /jcs>

< jcs>
This is a good point! It definitely broadens the attack surface...
< /jcs>

More fundamentally, I think it is misleading to imagine that intent
policies will be contained in one "file" (it is possible to do so but
impractical/cumbersome to manage). cf also the next comment.
[/LC]
<jcs>
See my previous reply. I am more worried about the user model -
constructing a single file means that the constructor has to know
implementation details. I think that this is unreasonable for the intent
writer. However, I see no reason why the intent compiler could not produce
a single file, or sets of files that group similar intent (e.g., invoking
multiple autonomic functions in the same ASA) together.
< /jcs>

[LC]
It is the "resolution" of the intent clauses that determines the domain/set
of target "nodes".
So in that order, yes the intent will be flooded to all the relevant nodes
in the "intent policy domain". This domain may be all nodes in an ANIMA
network, or a sub-set, only one node, or zero. This is contextual.
There will be *many* intent policies for a given ANIMA network.
[/LC]

<jcs>

Let's use a concept of:

   +--------+     +----------+     +-----------+

   | Intent |---->|  Intent  |---->| Autonomic |

   | Writer |     | Compiler |     |  Network  |

   +--------+     +----------+     +-----------+

I **think** what Laurent is saying is that once the Intent Compiler
resolves the intent of the user/intent writer, the target of the intent
policy is then identified. I agree with this. Even for the broad case of
"intent fabric", I don't think that an intent writer need be conscious of
this (vs. an autonomic function). Why should he or she care?

Laurent, please correct me if I am wrong here.

</jcs>

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 J

[LC]
I think we have a disconnect on what an intent look like and how it can be
used.
In my "mental model", there is not one "big" intent with sub-parts for each
ASA, the ANI, etc...
Each ASA designer (owner) will define the content / specificity of its ASA
functionality or links to the existing elements of the ANIMA intent policy
model, but it does not mean that we must aggregate all parts into a single
"file".
What would be the reason to do that?

In addition, there will not only be intent policies per functions, or for
the ANI.
There will be intent policies conveying the Service level, the Business
level... these will not resolve/map 1-to-1 in a single ASA "policy".
[/LC]

<jcs>

I don't think that you and Michael are really disagreeing (other than one
implementation (the file), which could be one option of many).

Indeed, in FOCALE and other work I have done, once intent was compiled, we
did group things together for a number of reasons (e.g., dependencies). I
think that the Autonomic Functions should advertise their capabilities, or
else, how does the Intent Compiler have a clue as to what gets shipped to
what (not to mention, how does it translate intent into a form that is
consumable by ASAs). This is even more important for Services - one could
imagine that a single Service intent would need multiple Autonomic
Functions to be implemented.

</jcs>

jcs>

<jcs>

See my previous reply. In short, I was worried about this requiring the
intent writer to be aware of which autonomic functions were present, and
the nature of the autonomic fabric. I don't care that much about the
structure of the input.

</jcs>

[LC]
I fully agree on the focus per autonomic function, but it does not imply to
have one single intent policy with all parts inside.
[/LC]

<jcs>

My point is that the intent writer should not have to have detailed
knowledge about how the autonomic network works, or what its constituent
autonomic functions are. In my previous post, I talked about an "autonomic
catalog" that the intent writer could use. This would hide the fact that a
particular service in the autonomic function had a 1:1 or 1:n
correspondence to a set of autonomic functions.

</jcs>

[LC]

<jcs>

Count me in.

</jcs>

regards,

John

On Wed, Mar 23, 2016 at 4:54 AM, Laurent Ciavaglia <
[email-masked]> wrote:

> *[stripped]*
> Before stating that intent policies should be flooded to all nodes, can we
> first compare/evaluate the different options?
> 1. flooding a "big" intent file (cf your current tentative example) may be
> bandwidth hungry, if one considers how frequently such an intent file could
> be distributed (ASA stop/start, device join/leave, policy change/update...)
> compared to distributing only what is required / where it is required.
> So in that order, yes the intent will be flooded to all the relevant nodes
> in the "intent policy domain". This domain may be all nodes in an ANIMA
> network, or a sub-set, only one node, or zero. This is contextual.
> There will be *many* intent policies for a given ANIMA network.
> [/LC]
>
> 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 J
>
> [LC]
> Each ASA designer (owner) will define the content / specificity of its ASA
> functionality or links to the existing elements of the ANIMA intent policy
> model, but it does not mean that we must aggregate all parts into a single
> "file".
> *From:* John Strassner [mailto:[email-masked] <[email-masked]>]
> *To:* Michael Behringer (mbehring) <[email-masked]>
> <[email-masked]>; John Strassner <[email-masked]>
> <[email-masked]>
> *Cc:* Duzongpeng <[email-masked]> <[email-masked]>;
> [email-masked]; Laurent Ciavaglia <[email-masked]>
> <[email-masked]>; Jéferson Campos Nobre
> <[email-masked]> <[email-masked]>; Sheng Jiang
> <[email-masked]> <[email-masked]>
> *From:* Anima [mailto: <[email-masked]>[email-masked]] *On
> Behalf Of *Duzongpeng
> *Cc:* Laurent Ciavaglia < <[email-masked]>
> [email-masked]>; Jéferson Campos Nobre <
> <[email-masked]>[email-masked]>; Sheng Jiang <
> <[email-masked]>[email-masked]>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 23 Mar 2016 20:40:37 -0700

Hi Alex,

I'm not sure I follow a couple of your points, please see inline...though
in retrospect, perhaps this is merely a case of who the actor is (in my
case, I am worried about the writer and user of intent, not how we build
it).

I really like your suggestion of flooding intent to all nodes (even if
there may be optimizations later).  It provides a level of conceptual
clarity.  Every node should be aware of overall intent (and need to decide
for itself if there are actions for it to take).

<jcs>

Why should **every** node be aware of all intent? Many times, this won't be
applicable.

The only reason I can see for doing this is to enable collaboration and/or
emergent behavior (in the AI sense). However, if you want emergent
behavior from autonomic nodes, then each node that is part of that
collaboration must interact. I don't think we know enough about this to
support or prohibit such behavior, other than this places an extra
requirement on the computational and reasoning abilities of the node.

If you have a different purpose, please do explain.

</jcs>

If there is some intent that applies only to some parts of the network and
not others, that can be addressed by using different Autonomic Domains.
And, of course, Autonomic Domains may be associated with certain Autonomic
Functions.  Intervention beyond intent should NOT be allowed for the
Autonomic Function(s) being served an Autonomic Domain, but of course other
interventions (for different functions, hence outside the scope) are still
possible.

<jcs>

I think that Autonomic Domains should (must?) be hidden from the
user/intent writer. They are clearly of huge internal benefit, but why
should the user of intent know about them? In addition, I think that we
should use roles as an indirection mechanism for scalability when working
with Autonomic Domains.

</jcs>

regards,

John

On Wed, Mar 23, 2016 at 10:56 AM, Alexander Clemm (alex) <[email-masked]>
wrote:

> clarity.  Every node should be aware of overall intent (and need to decide
> for itself if there are actions for it to take).
>
>
>
> If there is some intent that applies only to some parts of the network and
> not others, that can be addressed by using different Autonomic Domains.
> And, of course, Autonomic Domains may be associated with certain Autonomic
> Functions.  Intervention beyond intent should NOT be allowed for the
> Autonomic Function(s) being served an Autonomic Domain, but of course other
> interventions (for different functions, hence outside the scope) are still
> possible.
>
>
>
> --- Alex
>
>
>
> *From:* Anima [mailto:[email-masked]] *On Behalf Of *Michael
> Behringer (mbehring)
> *Cc:* Duzongpeng <[email-masked]>; Laurent Ciavaglia <
> [email-masked]>; Sheng Jiang <[email-masked]>;

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 23 Mar 2016 20:49:22 -0700

I am confused as to why we would consider prefix-management as an autonomic
intent. To me, this breaks a fundamental rule of what is intent by
requiring the intent writer to understand too many details about the target
of the intent. The analogy (at least in the ONF and TMF) was specifying to
a taxi company that you want a taxi, but you need to take a certain route,
because you (the customer) know traffic patterns better than the taxi
driver.

Surely we could pick a more appropriate example?

regards,
John

On Wed, Mar 16, 2016 at 5:41 AM, Duzongpeng <[email-masked]> wrote:

> regarding the “intent” example in “prefix-management ID” as an Autonomic
> intent.
>
>          It’s semantics are just like “all nodes of type x do this; type
> y does that”, so it is a high level policy.
>
>
>
> understandings exist (shown below). But perhaps they can be discussed later.
>
>
>
> Best
> Regards
>
> Zongpeng Du
>
>
>
> *From:* Michael Behringer (mbehring) [mailto:[email-masked]]
> *Sent:* Wednesday, March 16, 2016 4:17 PM
> *To:* Duzongpeng; [email-masked]
> *Cc:* Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
> *Subject:* RE: [Anima] Does Autonomic network need some intervention
> beyond intent
>
>
>
> Hi Zongpeng,
>
>
>
> Some default policies/parameters set through “intent” perhaps are
> fundamental for the uplayer services.
>
> It should be prevented that human operator uses some CLIs to change them
> by mistake, and the uplayer services are interrupted.
>
> The downside is that there is no “control” an//d people can do what they
> the network-level parameters for that function. This way is suitable to
> some relatively static functions.
>
> *From:* Anima [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Duzongpeng

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2016 17:52:35 +1300

> I am confused as to why we would consider prefix-management as an autonomic

It's the other way round. Prefix management was chosen as an autonomic use
case, so a follow-up question is: what intent is appropriate for that use case?

And the suggested answer is: the ISP's intent is that certain types
of edge network should get certain sizes of prefix. How the prefixes are
actually divided up and assigned is left to the autonomic nodes.

> To me, this breaks a fundamental rule of what is intent by

By all means describe other use cases and what sort of intent they need.

    Brian

---

From: John Strassner <[email-masked]>
Date: Wed, 23 Mar 2016 23:58:36 -0700

>> As Michael's yang outline showed, there will be network-wide aspects
>> to intent and also ASA-specific aspects. I think that in practice there
>> will be simple parameters in the ASA-specific parts, so (whether we
>> use yang or some other syntax) I see no advantage in having a
>> separate mechanism for the parameters - in a sense we never need
>> to answer the question, we simply treat all the information in the
>> same way, intent or parameter.

> Agree so far.

Sorry, I'm confused. Are we talking about intent having **parameters**?
Or are we talking about the output of the intent compiler generating
functions with parameters? Hopefully the latter...

>> Maybe we should think about levels of specialization. Top level,
>> network intent. Next level, intent for all ASAs supporting a given
>> objective. Those two levels would be flooded by GRASP. Next
>> level, intent for a single ASA. That would be transmitted by
>> unicast GRASP synchronization.

> Here I don't have the same view. The first two levels we agree on.
> Anything that's for a specific node doesn't qualify as "Intent" in my
> view. (Ignore that the flooding mechanism may contain unicast
> transmissions as part of the overall scheme).

Referring to the policy continuum, which I defined a long time ago
(let me know if you want references), there is a set of translations
from the most abstract level to a form suitable for consumption by
a device. This is because there are many different constituencies
that all **should be able to** work together, but have different
terminologies and concepts.

I'm not sure starting with "network intent" at the highest level is
correct. I'm not necessarily arguing for my original formulation
(which had business at the top and device implementation at the
bottom), but surely the greatest need for intent is for non *CIE
(25 cents to Michael) types?

> If Intent is a high-level policy (which I think we all agree on?)
> then I can think of two more "things" that are NOT Intent, to
> add to my list of "not-Intent":
>

Hmm. I **think** what you mean is if a specific node is directly
referenced in the intent statement, correct? (As opposed to if,
after the intent is compiled, the target is exactly one node.)

> - anything that's negotiated dynamically. (Intent is always
> originating from something non-technical - it's a policy).

Two observations:

    1) If it is non-technical (which I agree with), why are we
        talking about prefix-management? :-)
    2) This was a LONG, yet PAINFUL, discussion in both the
        ONF and the TMF. The specific counter-example used
        in the ONF was negotiating a taxi fare. One in the TMF
        was negotiating QoS and security. I think we need to
        be careful here about disallowing negotiation.

Agreed!

 > - anything that's not a "policy", ie doesn't come from a
> non-technical reasoning. (that's not a good way to define it,
> but can't think of a better one right now)

May be we should save this one for BA...

> I think you're suggesting an optimisation of Intent
> *distribution*, Brian, right? Where, if I know only a few
> nodes run a certain function, I just send that particular Intent
> to those nodes only? (is that what you're thinking of?)
>
> This would certainly be tempting, but I think it's a slippery
> slope, and would quickly get into conflict with current policy
> models. I'd prefer if we keep "our" Intent as "must be flooded
> everywhere". If it is really high level guidance, the optimization
> shouldn't be needed. Said differently: If we start pushing huge
> data models, maybe we're on the wrong track in the first place?

I think that the intent writer should be blissfully unaware of any
topology or specific autonomic function. It is up to the management
system (intent compiler plus appropriate logic) to figure out what
is meant by the intent, and where to push the intent.

Pushing huge data models seems unlikely at best. One exception
could be when an entire domain of diverse functions joins an
existing set of domains, AND the domains are expected to
interoperate and collaborate. I would view this as an exception,
and not the rule.

regards,
John

On Mon, Mar 21, 2016 at 2:31 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> Here I don't have the same view. The first two levels we agree on.
> Anything that's for a specific node doesn't qualify as "Intent" in my view.
> (Ignore that the flooding mechanism may contain unicast transmissions as
> part of the overall scheme).
>
> If Intent is a high-level policy (which I think we all agree on?) then I
> can think of two more "things" that are NOT Intent, to add to my list of
> "not-Intent":
>
> - anything that's negotiated dynamically. (Intent is always originating
> from something non-technical - it's a policy).
> - anything that's not a "policy", ie doesn't come from a non-technical
> reasoning. (that's not a good way to define it, but can't think of a better
> one right now)
>
> I think you're suggesting an optimisation of Intent *distribution*, Brian,
> right? Where, if I know only a few nodes run a certain function, I just
> send that particular Intent to those nodes only? (is that what you're
> thinking of?)
>
> This would certainly be tempting, but I think it's a slippery slope, and
> would quickly get into conflict with current policy models. I'd prefer if
> we keep "our" Intent as "must be flooded everywhere". If it is really high
> level guidance, the optimization shouldn't be needed. Said differently: If
> we start pushing huge data models, maybe we're on the wrong track in the
> first place?
>
> Michael
>
> > Regards
> >    Brian
> >
> > >>          You are welcome to contribute to the intent draft at any
> time, and
> > thanks in advance.
> > >>
> keep
> > >>          It's semantics are just like "all nodes of type x do this;
> type y does
> > that", so it is a high level policy.
> > >>
> personal
> > >> Yes, this is a recurring question and topic. Let me give my view on
> two
> > levels:
> > >>
> network, at
> existing and
> nodes of
> per
> Intent
> Intent is
> NOT
> > >> In other words: Let's not be too prescriptive, and hope that folks
> will do
> with as
> https://tools.ietf.org/html/draft-ietf-anima-
> high-level policy
> closed

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 24 Mar 2016 08:15:26 +0000

> Sent: 24 March 2016 04:04
> To: Michael Richardson <[email-masked]>; [email-masked]
> Subject: [Anima] Who's a proxy? [was: need for some ASA definitions
> definitions to help bootstrap]
> 
> >> These are things that *could* be determined by "power-on-above", i.e.
> >> a controller in the NOC could push (netconf-style or otherweise)
> >> configuration into a node to tell it, "You will be a bootstrap proxy
> >> on interfaces A,C and Q, and the registrar is at address BAR"
> >
> > link interfaces could be a proxy, and if the topology is
> > non-redundant, they would all need to be proxies.
> 

I don't see why it would matter. In fact, if you have many proxies, and if new devices pick at random, you'd even get some load balancing (if that matters). 

Simplicity rules. I suggest: 
- every device is always a proxy, by default
- admins have two options to stop the network expanding: 
  1) Intent "this network shall not expand any further" - will turn all proxies off everywhere
      (here is where the power of AN comes out!) 
  2) Local override through traditional means (e.g., config) 
     on an interface: "no autonomic" 
     on device level: "no autonomic proxy" 

Michael

> I don't think we need any input from a higher power. We just need the
> registrar to register itself with GRASP (so that it can be discovered) and the
> proxy instance in each node to execute the above algorithm once in a while.
> 
> Regards
>    Brian
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 24 Mar 2016 13:58:34 +0000

To answer whether the prefix management is a good use case for Intent: 

I think with this discussion we hit the hard reality we'll always hit from here on: Some folks would want to be more precise in their guidance than others. 

I think it's ok to convene in Intent: 
- "use prefix 192.168/16 for links of type x" (yes, there is an IP prefix in there, but I think we can allow this as a policy). 
- "block size for internal allocations to be /22" (again, this is really a parameter, so we shouldn't; but it still makes sense for today's netops, IMO)
- ... 

I'm sure some people will want to say: 
- in region A, use a /24 block
- in region B, use a /20 block, etc. 

Ideally an autonomic function could figure this out automatically. So, in an ideal world this shouldn't be in Intent. 

My personal view: Let's not be too prescriptive here at the moment; let people "play" and let us build experience first. Thus my statement "Intent should be divided into sections for autonomic functions, and it's up to the function owner to define the sub-structure, and how it's used." 

Michael

> Sent: 24 March 2016 05:53
> To: John Strassner <[email-masked]>; Duzongpeng
> <[email-masked]>
> <[email-masked]>; [email-masked]; Michael Behringer (mbehring)
> <[email-masked]>; Sheng Jiang <[email-masked]>
> > I am confused as to why we would consider prefix-management as an
> > autonomic intent.
> 
> It's the other way round. Prefix management was chosen as an autonomic
> use case, so a follow-up question is: what intent is appropriate for that use
> case?
> 
> And the suggested answer is: the ISP's intent is that certain types of edge
> network should get certain sizes of prefix. How the prefixes are actually
> divided up and assigned is left to the autonomic nodes.
> 
> > To me, this breaks a fundamental rule of what is intent by requiring
> > the intent writer to understand too many details about the target of
> > the intent. The analogy (at least in the ONF and TMF) was specifying
> > to a taxi company that you want a taxi, but you need to take a certain
> > route, because you (the customer) know traffic patterns better than
> > the taxi driver.
> >
> >>          Thanks for the reply. I can understand that intent is not in
> >> the current milestones, and you are working on several milestones drafts
> now.
> >>
> >>
> >>
> >> time, and thanks in advance.
> >>
> >>
> >>
> >> keep regarding the “intent” example in “prefix-management ID” as an
> >> Autonomic intent.
> >>
> >>          It’s semantics are just like “all nodes of type x do this;
> >> type y does that”, so it is a high level policy.
> >>
> >>
> >>
> >> means are more specific and can override intent. This is described in
> >> you mention
> >> high level, more along the line “do the right thing” J  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.
> >>
> >>
> >>
> >> The downside is that there is no “control” an//d people can do what
> >> 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.
> >>
> >>
> >>
> >> The first one is to define a policy first in every ASA, but with some
> >> open parameters that can be configured. What we need to do is just to
> >> distribute the network-level parameters for that function. This way
> >> is suitable to some relatively static functions.
> >>
> >> The second is more advanced, in the ideal case, the human operator
> >> can communicate with network using natural language or something
> >> similar. This way is more flexible, but harder to realize.
> >>
> >> [duzongpeng]
> >>
> >>
> >>
> >> 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]
> >> <[email-masked]>] *On Behalf Of *Duzongpeng
> >> *Cc:* Laurent Ciavaglia <[email-masked]>; Jéferson
> >> Campos Nobre <[email-masked]>; Sheng Jiang
> >> <[email-masked]>
> >> 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
> enterprise network.
> >> Perhaps we can rename the “intent” in the “prefix-management ID” to
> >> some other words.
> >>
> >>
> >>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 24 Mar 2016 14:01:47 +0000

> everywhere is probably cheap.  If that rate is high, I would want to be able to
> constrain the propagation.

Absolutely. And I cannot see how a "high level policy" would require a high update rate. Can anyone? (If not we can declare that question solved!)

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 11:37:52 -0400

Well, I do see folks wanting high rate policy interfaces.  I think it is 
quite sensible for us to note in some descriptive document that our 
target does not include very high rate repeated modification of the high 
level policies.

At which point I can live with just flooding the intents.

Yours,
Joel

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 24 Mar 2016 17:18:25 +0100

Hello,

I think we should distinguish 2 aspects:
     -the rate at which intent policies changes.
     -the rate at which intent policies are flooded.

I agree that, intuitively (we might need a more thorough evaluation), 
intent policy may not change too often.

On the other side, the rate at which intent policies are flooded may 
become "high" if the list of recipients changes frequently, or if other 
events trigger the need to flood some/all intent policies again.
It is not because an intent policy is not changed, that recipients (e.g. 
new ASA instances) should not be informed about the intent policies, and 
thus generates a new broadcast.

For me, it is not clear yet how often the intent policies are flooded, 
to whom and the "size" of such intent/flood traffic.

And so before jumping to some conclusion about the design, I would 
prefer if we dig a bit further in the analysis and evaluation.

Best regards, Laurent.

On 24/03/2016 16:37, EXT Joel M. Halpern wrote:
> Well, I do see folks wanting high rate policy interfaces.  I think it 
> is quite sensible for us to note in some descriptive document that our 
> target does not include very high rate repeated modification of the 
> high level policies.
>
>> Absolutely. And I cannot see how a "high level policy" would require 
>> a high update rate. Can anyone? (If not we can declare that question 
>> solved!)
>>
>> Michael
>>
>>>
>>> Yours,
>>> Joel
>>
>

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 24 Mar 2016 18:20:20 +0000

Hi John,

responses below, <ALEX>

--- Alex

... snip ...
I really like your suggestion of flooding intent to all nodes (even if there may be optimizations later).  It provides a level of conceptual clarity.  Every node should be aware of overall intent (and need to decide for itself if there are actions for it to take).
<jcs>
Why should **every** node be aware of all intent? Many times, this won't be applicable.

The only reason I can see for doing this is to enable collaboration and/or emergent behavior (in the AI sense). However, if you want emergent behavior from autonomic nodes, then each node that is part of that collaboration must interact. I don't think we know enough about this to support or prohibit such behavior, other than this places an extra requirement on the computational and reasoning abilities of the node.

If you have a different purpose, please do explain.
</jcs>
 <ALEX> Why should they _not_ be aware?  Now, granted, not every piece of intent affects every node.  That said, if we are talking about high-level intent here, and want to make it as easy as possible for users to interact with the Autonomic Network, why would we bother users or some other components with having to figure out which piece of intent might apply where?  A node will be able to determine on its own whether or not it needs to act on intent.  And yes, if you do want to implement emergent behavior with inter-node collaboration, you can introduce this without needing to expose how intent is implemented.
All this assumes that intent is not updated too frequently (the other discussion thread), and that the volume of intent is not prohibitive. However, if that were the case, arguably we are no longer talking about “intent” any more but other management mechanisms.
</ALEX>

If there is some intent that applies only to some parts of the network and not others, that can be addressed by using different Autonomic Domains.  And, of course, Autonomic Domains may be associated with certain Autonomic Functions.  Intervention beyond intent should NOT be allowed for the Autonomic Function(s) being served an Autonomic Domain, but of course other interventions (for different functions, hence outside the scope) are still possible.
<jcs>
I think that Autonomic Domains should (must?) be hidden from the user/intent writer. They are clearly of huge internal benefit, but why should the user of intent know about them? In addition, I think that we should use roles as an indirection mechanism for scalability when working with Autonomic Domains.
</jcs>
 <ALEX>
What you are saying is that you want your network to be a single autonomic domain that applies to all functions.  The main think is that I think you would want to avoid having to compute dependency graphs between objectives and trying to figure out which nodes within the domain should get one piece of intent but not another and at which point in time (as the autonomic network itself and the dependency graph may themselves undergo change).  In that case, allowing nodes to participate in a handful of separate domains may be conceptually a simpler model.
Cheers
--- Alex
 </ALEX>
... snip ...

---

From: John Strassner <[email-masked]>
Date: Thu, 24 Mar 2016 11:28:17 -0700

Note that policy (intent or otherwise) is not **just** about configuration.
I have used policy to define what should be monitored, and how to refine
the monitoring to get the data needed. This is a much higher rate of
running policies than adjusting them for configuration.

Note also that such policies can return a **lot** of data. For example, the
original example I gave (modified by Michael Richardson) was:

    Arrange VM guest distribution so that (CPU) utilization is < 70%

This does a potentially large amount of work, and could trigger additional
policies (intent or otherwise) depending on its results.

regards,
John

On Thu, Mar 24, 2016 at 8:37 AM, Joel M. Halpern <[email-masked]>
wrote:

> quite sensible for us to note in some descriptive document that our target
> does not include very high rate repeated modification of the high level
> policies.
>
>> Absolutely. And I cannot see how a "high level policy" would require a
>> high update rate. Can anyone? (If not we can declare that question solved!)
>>
>> Michael
>>
>>
>>> Yours,
>>> Joel
>>>
>>
>>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 24 Mar 2016 11:51:55 -0700

Hi Alex,

thanks for your replies, my responses in <jcs2>..</jcs2>

*... snip ...*

<jcs>

</jcs>

 <ALEX> Why should they _*not*_ be aware?  Now, granted, not every piece of
intent affects every node.  That said, if we are talking about high-level
intent here, and want to make it as easy as possible for users to interact
with the Autonomic Network, why would we bother users or some other
components with having to figure out which piece of intent might apply
where?
<jcs2>
The analogy is human conversations. Assume I am a manager. Why would I care
about **every** conversation my employees have?
Look at the example I gave (that Michael Richardson formulated better):

Why would nodes care about this if it wasn't applicable to them?
</jcs2>

A node will be able to determine on its own whether or not it needs to act
on intent.

</ALEX>
<jcs2>
In general, I disagree. That means that each node has to be able to
interpret intent. That is not going to happen for IoT devices. Even for
more computationally capable devices, how would they do this? Intent by
definition is high-level. I doubt that you and I (as practitioners in the
art) would come up with the same intent formulation.

Instead, I think that a management entity (e.g., an intent compiler) or a
set of such entities (possibly per domain, possibly spanning domains, this
doesn't matter right now) dedicated to the task of translating intent could
output a device-consumable formulation. That's totally reasonable, but is
different from what you said.
</jcs2>

And yes, if you do want to implement emergent behavior with inter-node
collaboration, you can introduce this without needing to expose how intent
is implemented.

All this assumes that intent is not updated too frequently (the other
discussion thread), and that the volume of intent is not prohibitive.
However, if that were the case, arguably we are no longer talking about
“intent” any more but other management mechanisms.
<jcs2>
We need to be careful. If the above intent example I gave is run over a
large data center, it could generate a lot of data. Note that the intent
itself is probably not run too frequently.
</jcs2>

<jcs>

</jcs>

 <ALEX>

What you are saying is that you want your network to be a single autonomic
domain that applies to all functions.  The main think is that I think you
would want to avoid having to compute dependency graphs between objectives
and trying to figure out which nodes within the domain should get one piece
of intent but not another and at which point in time (as the autonomic
network itself and the dependency graph may themselves undergo change).  In
that case, allowing nodes to participate in a handful of separate domains
may be conceptually a simpler model.

 </ALEX>
<jcs2>
That is not what I'm saying. Let me restate:

In order for autonomic networks to be of maximum utility to a user, a user
should not have to worry about which autonomic domains are present, and
which autonomic functions are contained in which autonomic domain.

This has nothing to do with compressing the internal topology to a single
autonomic domain - it is the **user model** that I am talking about.
</jcs2>

regards,
John

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 24 Mar 2016 19:31:48 +0000

Hi John
inline,<AC>
--- Alex

From: John Strassner [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 11:52 AM
To: Alexander Clemm (alex) <[email-masked]>; John Strassner <[email-masked]>
Cc: Michael Behringer (mbehring) <[email-masked]>; Duzongpeng <[email-masked]>; Laurent Ciavaglia <[email-masked]>; Sheng Jiang <[email-masked]>; [email-masked]; Jéferson Campos Nobre <[email-masked]>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Hi Alex,

... snip ...

If you have a different purpose, please do explain.
</jcs>
 <ALEX> Why should they _not_ be aware?  Now, granted, not every piece of intent affects every node.  That said, if we are talking about high-level intent here, and want to make it as easy as possible for users to interact with the Autonomic Network, why would we bother users or some other components with having to figure out which piece of intent might apply where?
<jcs2>
The analogy is human conversations. Assume I am a manager. Why would I care about **every** conversation my employees have?
Look at the example I gave (that Michael Richardson formulated better):

A node will be able to determine on its own whether or not it needs to act on intent.
</ALEX>
<jcs2>
In general, I disagree. That means that each node has to be able to interpret intent. That is not going to happen for IoT devices. Even for more computationally capable devices, how would they do this? Intent by definition is high-level. I doubt that you and I (as practitioners in the art) would come up with the same intent formulation.

Instead, I think that a management entity (e.g., an intent compiler) or a set of such entities (possibly per domain, possibly spanning domains, this doesn't matter right now) dedicated to the task of translating intent could output a device-consumable formulation. That's totally reasonable, but is different from what you said.
</jcs2>

<AC> The goals with autonomic networks is to make it as easy as possible to manage/”guide” network behavior.  I am just looking at it from the user perspective:  Anything that requires me to differentiate what I need to communicate to whom makes things a little more difficult – I may have forgotten someone, I may have inadvertently communicated conflicting intent, etc.  You are correct in that there are practical considerations that make it hard to implement this.

You are right to point out that some devices may not be able to support intent.  This is why there is still policy-based management etc; that doesn’t go away and continues to exist. One aspect that is probably needed is a reporting function that tells a user which devices support intent and which don’t and need to be managed using other means .
<AC>

And yes, if you do want to implement emergent behavior with inter-node collaboration, you can introduce this without needing to expose how intent is implemented.
All this assumes that intent is not updated too frequently (the other discussion thread), and that the volume of intent is not prohibitive. However, if that were the case, arguably we are no longer talking about “intent” any more but other management mechanisms.
<jcs2>
We need to be careful. If the above intent example I gave is run over a large data center, it could generate a lot of data. Note that the intent itself is probably not run too frequently.
</jcs2>

In order for autonomic networks to be of maximum utility to a user, a user should not have to worry about which autonomic domains are present, and which autonomic functions are contained in which autonomic domain.

This has nothing to do with compressing the internal topology to a single autonomic domain - it is the **user model** that I am talking about.
</jcs2>

<AC> OK, I think we are agreeing on to making it easy on the user.  We do not want to have users having to worry about distinctions between different devices /nodes in an autonomic network etc when communicating network intent.</AC>

regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 08:43:56 +1300

On 25/03/2016 05:18, Laurent Ciavaglia wrote:
...
> It is not because an intent policy is not changed, that recipients (e.g. new ASA instances) should not be informed about the intent policies, and thus generates a new broadcast. 

A newly started ASA can (and probably should) perform the following logic:

 - discover the Intent server (just another ASA, of course)
 - request unicast synchronization of the latest intent

Actually the same applies to sleeping nodes: at some frequency
they should wake up and synchronize intent, or any other flooded
objective that they care about. This is already specified in GRASP:
  "Sleeping nodes that require an objective subject to flooding SHOULD
   periodically request unicast synchronization for that objective."

That doesn't mean than periodic re-flooding is forbidden, but the frequency
can be kept quite low.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 08:50:38 +1300

On 25/03/2016 07:20, Alexander Clemm (alex) wrote:
...
> <ALEX> Why should they _not_ be aware?  Now, granted, not every piece of intent affects every node. 

We don't know in advance. At any time, a new ASA might start in any node that
depends on some intent item not previously needed in that node. Now, as I just
said to Laurent, that ASA needs to synchronize relevant intent. If it has previously
been flooded to all nodes, this should be possible without any new messages.
(Hmm. I need to check whether the GRASP rules about caching flooded data
guarantee that already, but I think so.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 08:55:30 +1300

On 25/03/2016 07:51, John Strassner wrote:
...
>> In general, I disagree. That means that each node has to be able to interpret intent. That is not going to happen for IoT devices.

IoT devices are out of scope here - Anima is for devices that can actually support
quite complex software. Intent for managing a bunch of IoT devices is in scope,
of course.

    Brian

---

From: John Strassner <[email-masked]>
Date: Thu, 24 Mar 2016 13:08:14 -0700

Thanks Alex, I think we do indeed agree again.

regards,
John

On Thu, Mar 24, 2016 at 12:31 PM, Alexander Clemm (alex) <[email-masked]>
wrote:

> *Sent:* Thursday, March 24, 2016 11:52 AM
> *To:* Alexander Clemm (alex) <[email-masked]>; John Strassner <
> [email-masked]>
> *Cc:* Michael Behringer (mbehring) <[email-masked]>; Duzongpeng <
> [email-masked]>; Laurent Ciavaglia <[email-masked]>;
> Sheng Jiang <[email-masked]>; [email-masked]; Jéferson Campos
> Nobre <[email-masked]>
>  <ALEX> Why should they _*not*_ be aware?  Now, granted, not every piece
> of intent affects every node.  That said, if we are talking about
> high-level intent here, and want to make it as easy as possible for users
> to interact with the Autonomic Network, why would we bother users or some
> other components with having to figure out which piece of intent might
> apply where?
>
> <jcs2>
>
> The analogy is human conversations. Assume I am a manager. Why would I
> care about **every** conversation my employees have?
>
> <AC> The goals with autonomic networks is to make it as easy as possible
> to manage/”guide” network behavior.  I am just looking at it from the user
> perspective:  Anything that requires me to differentiate what I need to
> communicate to whom makes things a little more difficult – I may have
> forgotten someone, I may have inadvertently communicated conflicting
> intent, etc.  You are correct in that there are practical considerations
> that make it hard to implement this.
>
>
>
> You are right to point out that some devices may not be able to support
> intent.  This is why there is still policy-based management etc; that
> doesn’t go away and continues to exist. One aspect that is probably needed
> is a reporting function that tells a user which devices support intent and
> which don’t and need to be managed using other means .
>
> <AC>
>
>
>
> <AC> OK, I think we are agreeing on to making it easy on the user.  We do
> not want to have users having to worry about distinctions between different
> devices /nodes in an autonomic network etc when communicating network
> intent.</AC>
>
>
>
> regards,
>
> John
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 24 Mar 2016 13:13:31 -0700

I may be getting old, but I seem to recall concern over "constrained
nodes" being able to use ANIMA being discussed at several
previous meetings and on the mail list. I re-read the charter, and do
not find such devices explicitly mentioned.

However, the point was that if intent is indeed high-level, then
without a standard lexicon, it will be virtually impossible to ensure
that different devices could process intent directly from the user.

regards,
John

On Thu, Mar 24, 2016 at 12:55 PM, Brian E Carpenter <
[email-masked]> wrote:

> interpret intent. That is not going to happen for IoT devices.
>

-- 
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 24 Mar 2016 22:21:06 +0100

Brian,

> That doesn't mean than periodic re-flooding is forbidden, but the frequency

Agreed.
So, there are at least two mechanisms involved concerning intent 
"distribution":
     -flooding (when intent is created, updated, etc.)
and
     -unicast or pub/sub or ... for the cases we described.

Michael B./all: do you agree with the above? does it make a case for 
considering more than only flooding as the mechanism for intent 
distribution?

Thanks, best regards,
Laurent.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 10:38:08 +1300

> not find such devices explicitly mentioned.

Of course it's hard to define the dividing line, but I've always
thought: light switches, no; lighting controllers, maybe;
building management controllers, yes. I certainly don't expect
an intelligent light switch to process intent items like "energy
policy = maximum savings".

> that different devices could process intent directly from the user.

Agreed. We have to get to that point (but later, according to the
WG Charter).

   Brian

---

From: John Strassner <[email-masked]>
Date: Thu, 24 Mar 2016 14:53:56 -0700

OK, thanks Brian, the light bulb switched on. :-)

regards,
John

On Thu, Mar 24, 2016 at 2:38 PM, Brian E Carpenter <
[email-masked]> wrote:

> >> IoT devices are out of scope here - Anima is for devices that can
> actually
> >> support

-- 
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 25 Mar 2016 00:37:05 +0100

Hi John,

Thanks for your comments.
Please see below [lc2][/lc2].

On 24/03/2016 04:22, EXT John Strassner wrote:
>
> Hi Laurent,
>
> Thanks for your note. I'd be happy to join in a virtual meeting. 
> Please see <jcs>..</jcs> for my observations.
>
> implementation details. I think that this is unreasonable for the 
> intent writer. However, I see no reason why the intent compiler could 
> not produce a single file, or sets of files that group similar intent 
> (e.g., invoking multiple autonomic functions in the same ASA) together.
> < /jcs>
[lc2]: Fully agree. I was thinking about the user model. The output of 
the intent compiler could be a single file, I am fine with that.[/lc2]

> nodes in the "intent policy domain". This domain may be all nodes in 
> an ANIMA network, or a sub-set, only one node, or zero. This is 
> contextual.
> There will be *_many_* intent policies for a given ANIMA network.
> [/LC]
>
> <jcs>
>
> Let's use a concept of:
>
> resolves the intent of the user/intent writer, the target of the 
> intent policy is then identified. I agree with this. Even for the 
> broad case of "intent fabric", I don't think that an intent writer 
> need be conscious of this (vs. an autonomic function). Why should he 
> or she care?
>
[lc2]: You read me right.[/lc2]
> bit of
> 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 J
>
> [LC]
> ASA functionality or links to the existing elements of the ANIMA 
> intent policy model, but it does not mean that we must aggregate all 
> parts into a single "file".
> There will be intent policies conveying the Service level, the 
> Business level... these will not resolve/map 1-to-1 in a single ASA 
> "policy".
> [/LC]
>
> <jcs>
>
> I don't think that you and Michael are really disagreeing (other than 
> one implementation (the file), which could be one option of many).
>
> Indeed, in FOCALE and other work I have done, once intent was 
> compiled, we did group things together for a number of reasons (e.g., 
> dependencies). I think that the Autonomic Functions should advertise 
> their capabilities, or else, how does the Intent Compiler have a clue 
> as to what gets shipped to what (not to mention, how does it translate 
> intent into a form that is consumable by ASAs). This is even more 
> important for Services - one could imagine that a single Service 
> intent would need multiple Autonomic Functions to be implemented.
>
> </jcs>
>
[lc2]:I fully agree, weused a same approach in UNIVERSELF for the policy 
continuum from the operator high-level policy input to the service- and 
network-levels policy translation.
and indeed, for the service-level this is a key aspect (mapping the 
autonomic functions contributing/involved/impacting the services).[/lc2]

> _
> _
> See my previous reply. In short, I was worried about this requiring 
> the intent writer to be aware of which autonomic functions were 
> present, and the nature of the autonomic fabric. I don't care that 
> much about the structure of the input.
>
> </jcs>
>
[lc2]: I agree, it is still early to discuss the structure/format of the 
intent, but my point was to start thinking about what a common intent 
format would look like for the ASAs, to ensure a certain level of 
interoperability and automation in the processing of the intent. This is 
linked to what you say below/in another message on the ASA capabilities 
being advertised/registered.[/lc2]
> I fully agree on the focus per autonomic function, but it does not 
> imply to have one single intent policy with all parts inside.
> [/LC]
>
> <jcs>
>
> knowledge about how the autonomic network works, or what its 
> constituent autonomic functions are. In my previous post, I talked 
> about an "autonomic catalog" that the intent writer could use. This 
> would hide the fact that a particular service in the autonomic 
> function had a 1:1 or 1:n correspondence to a set of autonomic functions.
>
> </jcs>
>
[lc2]: I agree with the catalog approach. This relates to what we have 
tried to push in different drafts with the life-cycle of ASA, where ASA 
need to register or be discovered, for governance, coordination or 
information/knowledge purposes.[/lc2]

> Can we schedule a face-to-face ad-hoc meeting?
[lc]: ok. I will see how to set this up, and will keep the WG/interested 
participants posted.[/lc2]
thank, best regards, Laurent.

> regards,
>
> John
>
>
> On Wed, Mar 23, 2016 at 4:54 AM, Laurent Ciavaglia 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Michael,
>
>>     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,
>     Before stating that intent policies should be flooded to all
>     nodes, can we first compare/evaluate the different options?
>     1. flooding a "big" intent file (cf your current tentative
>     example) may be bandwidth hungry, if one considers how frequently
>     such an intent file could be distributed (ASA stop/start, device
>     join/leave, policy change/update...) compared to distributing only
>     what is required / where it is required.
>     (possibly undesirable/rogue) entities that do not need it (and
>     thus may mis-use it).
>
>     More fundamentally, I think it is misleading to imagine that
>     intent policies will be contained in one "file" (it is possible to
>     do so but impractical/cumbersome to manage). cf also the next comment.
>     [/LC]
>
>     So in that order, yes the intent will be flooded to all the
>     relevant nodes in the "intent policy domain". This domain may be
>     all nodes in an ANIMA network, or a sub-set, only one node, or
>     zero. This is contextual.
>>     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 J
>>
>     [LC]
>     Each ASA designer (owner) will define the content / specificity of
>     its ASA functionality or links to the existing elements of the
>     ANIMA intent policy model, but it does not mean that we must
>     aggregate all parts into a single "file".
>     There will be intent policies conveying the Service level, the
>     Business level... these will not resolve/map 1-to-1 in a single
>     ASA "policy".
>     [/LC]
>
>>     <jcs>
>>
>>     section for the fabric, and sections for the various functions.
>>     Seems a natural structure?!?
>>
>     [LC]
>     It is OK to have different intent-policies for the fabric and for
>     the functions, but why put them all into one file/policy?
>     [/LC]
>>
>>     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.
>>
>     [LC]
>     I fully agree on the focus per autonomic function, but it does not
>     imply to have one single intent policy with all parts inside.
>     [/LC]
>
>>     <mailto:[email-masked]>; John Strassner <[email-masked]>
>>     <mailto:[email-masked]>
>>     *Cc:* Duzongpeng <[email-masked]>
>>     <mailto:[email-masked]>; [email-masked]
>>     <[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
>>
>>     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>
>>
>>     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” J
>>
>>     <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
>>     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>
>>
>>     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>
>>
>>     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>
>>
>>     NOT what Intent is meant to do.
>>
>>     <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
>>         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” JIt 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.
>>
>>         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:<mailto:[email-masked]>[email-masked]
>>         *Cc:* Laurent Ciavaglia
>>         <<mailto:[email-masked]>[email-masked]
>>         <<mailto:[email-masked]>[email-masked]
>>         <mailto:[email-masked]>>; Sheng Jiang
>>         <<mailto:[email-masked]>[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.
>>
>>         (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.
>>
>>         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.
>>
>>         2.Relatively static compared to intent, perhaps only needed
>>         to be configured once
>>
>>         4.Rarely need coordinations with others parameters, usually
>>         is closed related to one specific autonomic function
>>
>     LinkedIn: laurentciavaglia
>     <http://fr.linkedin.com/in/laurentciavaglia/>
>
>
>
>
> -- 
> regards,
> John

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 25 Mar 2016 00:37:14 +0100

Hi John,

[lc]: ok. I will see how to set this up, and will keep the WG/interested 
participants posted.[/lc2]
Thanks, best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Duzongpeng <[email-masked]>
Date: Fri, 25 Mar 2016 03:31:19 +0000

Hi  John

Sorry for the late response. Please see inline.

From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, March 22, 2016 6:51 AM
To: Duzongpeng; John Strassner
Cc: [email-masked]; Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

<jcs>
I agree configurations are always needed, but Autonomic network may make internal configurations kind of transparent to human operator.
[duzongpeng]

<jcs>

[duzongpeng]
IMO, it is ok what the definition of intent is, and ANIMA should reuse the intent-related work in other places, at list should not conflict with them.
I think in ANIMA, we are just trying to fulfill the requirement of some ASAs, in which intent shows to be helpful.
Whether it is called intent or something else is secondary.
[duzongpeng]

<jcs>

[duzongpeng]
I fully agree that it is implementation-specific, so I have suggested that more use cases or ASA examples are needed here.
One example is underneath.
[duzongpeng]

         For example, in the
 https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00<https://tools.ietf.org/html/draft-ietf-anima-prefix-management-00>,

<jcs>

[duzongpeng]
I agree multiple ways exist.
But, it can be an intent under specific contexts.
We can have intent for application users, and intent for network operators. IMO, we should make ANIMA network convenient for different kinds of users.
Again, if not called intent here, and we can find some other name, it is ok for me.
[duzongpeng]

<jcs>

<jcs>

[duzongpeng]
I agree works are needed for translating intent.
Currently, figuring out the scope of ANIMA intent is also important.
[duzongpeng]

regards,
John

On Tue, Mar 15, 2016 at 6:37 PM, Duzongpeng <[email-masked]<mailto:[email-masked]>> wrote:
Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 25 Mar 2016 07:54:34 +0000

> Sent: 24 March 2016 20:44
> To: Laurent Ciavaglia <[email-masked]>; EXT Joel M. Halpern
> <[email-masked]>; Michael Behringer (mbehring)
> <[email-masked]>
> Cc: Duzongpeng <[email-masked]>; [email-masked]; Sheng Jiang
> <[email-masked]>
> Subject: Re-flooding [was: Does Autonomic network need some intervention
> beyond intent]
> 
> > It is not because an intent policy is not changed, that recipients (e.g. new
> ASA instances) should not be informed about the intent policies, and thus
> generates a new broadcast.
> 
> Actually the same applies to sleeping nodes: at some frequency they should
> wake up and synchronize intent, or any other flooded objective that they
> care about. This is already specified in GRASP:

Hmmm... To me, keeping Intent up to date is not a function of the ASAs at all. 

In my mind, Intent management, synchronisation etc are functions of the AN Infrastructure. In the AN Infrastructure there is a functional block "Intent management". That keeps Intent in sync with neighbouring nodes. Up to this point the ASAs aren't even involved. 

An ASA has an interface into the ANI, which allows it to request "its" Intent. Or, the ANI pushes the respective Intent to the ASA. 

But my main point: ASAs shouldn't know about synchronisation or distribution. They just consume what's on the node (in the ANI). 
 
> That doesn't mean than periodic re-flooding is forbidden, but the frequency

And regarding periodic flooding: Depends on the overall model. If we keep reliable connections between nodes (a la BGP) then re-flooding is not required as long as the session is up. If we use unreliable transport, then I personally would prefer a two phase process: 
1) a "ping" just with the version number of Intent
2) If one side has a lower than the other, it pulls it reliably. 

There are many other ways of doing it, I guess that's a discussion for BA. 

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 25 Mar 2016 08:00:10 +0000

I think we have a misunderstanding in terminology.

When I say “flooding” I mean that the same Intent data structure is passed on hop by hop through the entire network and every node sees exactly the same data structure.

This may be implemented by passing the Intent file hop by hop in a unicast transmission. The key being “hop by hop”.

When I hear the word “unicast” I suspect that some people mean “unicast to a remote node” or to an “Intent server”. That I don’t think is necessary, and will make things more complex.

Michael

From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: 24 March 2016 22:21
To: EXT Brian E Carpenter <[email-masked]>; Laurent Ciavaglia <[email-masked]>; EXT Joel M. Halpern <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>
Cc: Duzongpeng <[email-masked]>; [email-masked]; Sheng Jiang <[email-masked]>
Subject: Re: [Anima] Re-flooding [was: Does Autonomic network need some intervention beyond intent]

Brian,

...

can be kept quite low.

Agreed.
So, there are at least two mechanisms involved concerning intent "distribution":
    -flooding (when intent is created, updated, etc.)
and
    -unicast or pub/sub or ... for the cases we described.

Michael B./all: do you agree with the above? does it make a case for considering more than only flooding as the mechanism for intent distribution?

Thanks, best regards,
Laurent.

---

From: Duzongpeng <[email-masked]>
Date: Fri, 25 Mar 2016 08:30:52 +0000

Hi, John

Some personal understandings for discussion.

<jcs>

I think I can understand your idea. However, it looks like a top-down method.

It has been suggested that ANIMA can work by using a bottom-up method.

I mean perhaps we can make a minimum set for intent right now, and make it work first.

It has been suggested that ANIMA ASAs will be developed in a one-by-one procedure, so that currently there is not too much information that needed to be carried in the intent.

I think that is why Michael has said intent should be a small one.

In the ideal, AFA will finally be transparent for intent. Perhaps, it is because most of the need of operator can be expressed using abstract languages.

But in current status, it is not practical that an intent writer in ANIMA network do not know the information about autonomic functions in the autonomic domain.

Best Regards
Zongpeng Du

From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, March 23, 2016 4:32 AM
To: Michael Behringer (mbehring); John Strassner
Cc: Duzongpeng; [email-masked]; Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Fri, 25 Mar 2016 08:56:42 +0000

Hi John

Some personal understanding here. If any misunderstanding here, please correct me.

<jcs>

I fully agree that we should consider actors that are using intent. But it does not mean that a network expert does not need intent.

Of course, a network expert can management the network without intent. But it does not mean that they would like to do the detailed configuration node-by-node repeatedly.

I think one of the advantages of ANIMA network is that it can relieve the work of the network operator.

When ANIMA network is adopted, the network operator can focus on something ANIMA network can not do, for example,  some high-level design or high-level management.

Best Regards
Zongpeng Du

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Fri, 25 Mar 2016 09:31:01 +0000

Hi John

Some personal understanding here. If any misunderstanding, please correct me. Thanks.

<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]] 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]; 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.

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.
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>

regards,
John

On Wed, Mar 23, 2016 at 3:57 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:
John,

<jcs>

Michael

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--
regards,
John

---

From: peter van der Stok <[email-masked]>
Date: Fri, 25 Mar 2016 11:24:38 +0100

I would not worry too much about for example sleepy nodes.
Flooding is OK as long it is possible to to limit the distribution 
(based on MC address)
For example, Sleepy nodes will have private (probably standardized) 
mechanisms to obtain the info when needed from its parent.

Peter

---

From: Duzongpeng <[email-masked]>
Date: Fri, 25 Mar 2016 11:43:10 +0000

Hi, John, Alex:

         Some personal understanding below. Please see inline.

Best regards
Zongpeng Du

From: John Strassner [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 11:41 AM
To: Alexander Clemm (alex); John Strassner
Cc: Michael Behringer (mbehring); Duzongpeng; Laurent Ciavaglia; Sheng Jiang; [email-masked]; Jéferson Campos Nobre
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Hi Alex,

I'm not sure I follow a couple of your points, please see inline...though in retrospect, perhaps this is merely a case of who the actor is (in my case, I am worried about the writer and user of intent, not how we build it).

If you have a different purpose, please do explain.
</jcs>
[duzongpeng]
I agree that we can have every node in the autonomic domain have the same intent. Within my understanding, it can be a candidate solution.

The advantage of the solution is simple. By using some synchronization mechanism, it makes all the node in the autonomic domain can work cooperatively.

Another consideration is that when a new node join in the autonomic domain, perhaps it can receive the intent from its neighbor.

I means Administrative Intent here, not a service intent. (Section 8 of https://tools.ietf.org/html/draft-du-anima-an-intent-03)

Perhaps the later only needs to be distributed to the related node, not all the node.

The service intent may even be related to multiple autonomic domains.
[/duzongpeng]

If there is some intent that applies only to some parts of the network and not others, that can be addressed by using different Autonomic Domains.  And, of course, Autonomic Domains may be associated with certain Autonomic Functions.  Intervention beyond intent should NOT be allowed for the Autonomic Function(s) being served an Autonomic Domain, but of course other interventions (for different functions, hence outside the scope) are still possible.
<jcs>
I think that Autonomic Domains should (must?) be hidden from the user/intent writer. They are clearly of huge internal benefit, but why should the user of intent know about them? In addition, I think that we should use roles as an indirection mechanism for scalability when working with Autonomic Domains.
</jcs>
[duzongpeng]
Within my understanding, an autonomic domain will have an intent, and it can only take effect within this domain.

When a user issues an intent, she/he should know the domain name. I mean an intent can contain the domain name as one of its element.

I agree that using roles is good for scalability.
[/duzongpeng]

regards,
John

On Wed, Mar 23, 2016 at 10:56 AM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>> wrote:
I really like your suggestion of flooding intent to all nodes (even if there may be optimizations later).  It provides a level of conceptual clarity.  Every node should be aware of overall intent (and need to decide for itself if there are actions for it to take).

--- Alex

From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Behringer (mbehring)
Sent: Wednesday, March 23, 2016 3:57 AM
To: John Strassner <[email-masked]<mailto:[email-masked]>>
Cc: Duzongpeng <[email-masked]<mailto:[email-masked]>>; Laurent Ciavaglia <[email-masked]<mailto:[email-masked]>>; Sheng Jiang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jéferson Campos Nobre <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

John,

<jcs>

Michael

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--
regards,
John

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 25 Mar 2016 18:18:25 +0000

Hi Zongpeng,

looking at your comments, I completely agree.  I think we’re on the same page.

Regards
--- Alex

From: Duzongpeng [mailto:[email-masked]]
Sent: Friday, March 25, 2016 4:43 AM
To: John Strassner <[email-masked]>; Alexander Clemm (alex) <[email-masked]>
Cc: Michael Behringer (mbehring) <[email-masked]>; Laurent Ciavaglia <[email-masked]>; Sheng Jiang <[email-masked]>; [email-masked]; Jéferson Campos Nobre <[email-masked]>
Subject: RE: [Anima] Does Autonomic network need some intervention beyond intent

Hi, John, Alex:

Best regards
Zongpeng Du

Cc: Michael Behringer (mbehring); Duzongpeng; Laurent Ciavaglia; Sheng Jiang; [email-masked]<mailto:[email-masked]>; Jéferson Campos Nobre

Hi Alex,

regards,
John

--- Alex

John,

<jcs>

Michael

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--
regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Mar 2016 15:55:46 -0400

John Strassner <[email-masked]> wrote:
    > <jcs> Hopefully, intent will not change frequently (or else it probably
    > is too low level in nature). I personally like using pub-sub, but that
    > is because it enables me to do additional pre- and post-processing of
    > intent. However, I think that this should be an option.  < /jcs>

Why not flood the list of intents (by suitable-hash of intent file), and
along with an origin for the intent.  (this winds up looking a lot like
OSPF, and is what DNCP is good at...)

Then, any node which does not have a copy of that intent can ask for it using
any of our well known protocols (i.e. HTTP).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 09:06:18 +1300

Hi Michael,

> Hmmm... To me, keeping Intent up to date is not a function of the ASAs at all. 

Well, that requirement is about a sleeping *node* which could contain any
number of ASAs.

> In my mind, Intent management, synchronisation etc are functions of the AN Infrastructure. In the AN Infrastructure there is a functional block "Intent management". That keeps Intent in sync with n…

Yes, if we model Intent as a single data structure distributed to all nodes.
(I would actually model it as a generic ASA called "Intent" that handles a generic
objective called "Intent", because that way we can use bog-standard GRASP
to handle Intent.)

> An ASA has an interface into the ANI, which allows it to request "its" Intent. Or, the ANI pushes the respective Intent to the ASA. 

Sure. But again we can model it in the same way, "Intent.PrefixManager" being the
Intent relevant to the "PrefixManager" objective.

> But my main point: ASAs shouldn't know about synchronisation or distribution. They just consume what's on the node (in the ANI). 

All ASAs know about synchronization because it's a generic function.
However, again we can use the same model. To be very concrete:

 ok, intent = grasp.synchronize(asa_nonce, grasp.objective("Intent.PrefixManager"), None, None)

That will fetch the requested intent from the local flood cache, if it's there,
or figure out where to fetch it if it's not there.

I could code an Intent system in Python in a couple of days, I think.

> And regarding periodic flooding: Depends on the overall model. If we keep reliable connections between nodes (a la BGP) then re-flooding is not required as long as the session is up. 

I have a tendency to prefer stateless solutions where possible, because under
adverse conditions such as intermittent connectivity the tend to survive better.

> If we use unreliable transport, then I personally would prefer a two phase process: 

That works if there is a single source of Intent. It gets more tricky
if there are multiple sources.

> 2) If one side has a lower than the other, it pulls it reliably.

Sure. That's actually why I prefer TCP for GRASP unicast operations, which
will always be the backup if flooding fails.

Rgds
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Mar 2016 16:17:49 -0400

> 1. Does it matter if there is more than one proxy on a given LAN?

No, it's fine.
What matters is that there is at least one *legitimate* proxy on a given LAN.

That means that a potential proxy can not just look for the *insecure* proxy
announcement (it could be an attacker), it has to communicate securely to
indicate to other proxies to indicate it is legit.  Or, just always become a
proxy.

    >    1. Do I have more than one LAN interface?  If no, I cannot be a
    > proxy; exit 2.

All machines that participate in the ACP have more than one interface!
Okay, change that to more than one physical interface...

I can see your point that if a device has only one physical interface
(accounting for multiple wifi channels and multiple lambdas...) that being a
proxy is pointless... the other device at the other end of the near ACP hop
ought to be legitimate and can operate a proxy.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Mar 2016 16:20:16 -0400

> I don't see why it would matter. In fact, if you have many proxies, and
    > if new devices pick at random, you'd even get some load balancing (if
    > that matters).

The other reason is that if you have more legitimate proxies than rogue
proxies the odds of the new node picking a legitimate proxy goes up.

    > (here is where the power of AN comes out!)

maybe the intent would say, "maximum layer-3 hops is X"

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:30:04 +1300

> When I hear the word “unicast” I suspect that some people mean “unicast to a remote node” or to an “Intent server”. That I don’t think is necessary, and will make things more complex.

But we already need that for specific ASA-to-ASA synchronization (or negotiation,
but I assume Intent is non-negotiable). So it really isn't additional complexity.
As the example in my previous mail suggests, an ASA in need of intent doesn't
really care whether the GRASP engine got the Intent by flooding or by point-to-point
synchronization.

I do agree that the ASA shouldn't need to know the details; it just needs a way
to get the current Intent.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 13:41:42 +1300

> OSPF, and is what DNCP is good at...)

Sure, if it turns out that we need such a mechanism, there are plenty
of precedents.

> any of our well known protocols (i.e. HTTP).

Well, this would also fit immediately into GRASP too. Just add a "virtual"
objective called "Intent.Hash" which you could synchronize any time, and
if it doesn't match your local hash, you know you need to resynch "Intent".

    Brian

---

From: John Strassner <[email-masked]>
Date: Fri, 25 Mar 2016 18:04:35 -0700

Hi Zongpeng,

Let me try to rephrase. It isn't a question of top-down or bottom-up, but
rather, how complex the user model is. I am recommending a simple user
model. This means that the user should not have to know in advance the list
of specific autonomic functions that are present.

I do agree that we should start simple. One autonomic function is fine.
However, I don't understand why you say that "it is not practical that an
intent writer in ANIMA network do not know the information about autonomic
functions in the autonomic domain". Intent shouldn't be a function call or
an API. It should be expressed in a form natural to the intent writer, and
then translated to a form that a device can consume.

regards,
John

On Fri, Mar 25, 2016 at 1:30 AM, Duzongpeng <[email-masked]> wrote:

> It has been suggested that ANIMA ASAs will be developed in a one-by-one
> procedure, so that currently there is not too much information that needed
> to be carried in the intent.
>
>
>
> In the ideal, AFA will finally be transparent for intent. Perhaps, it is
> because most of the need of operator can be expressed using abstract
> languages.
>
>
>
> But in current status, it is not practical that an intent writer in ANIMA
> network do not know the information about autonomic functions in the
> autonomic domain.
>
>
>
> Best Regards
>
> Zongpeng Du
>
>
>
>
>
> *Sent:* Wednesday, March 23, 2016 4:32 AM
> *To:* Michael Behringer (mbehring); John Strassner
> *Cc:* Duzongpeng; [email-masked]; Laurent Ciavaglia; Jéferson Campos
> Nobre; Sheng Jiang

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 14:08:36 +1300

Ack to all that. One minor comment below...
> ought to be legitimate and can operate a proxy.

Yes, exactly. It's exactly the same for the question whether a node
acts as a GRASP relay: only if it has multiple physical links.

Now, I just need a socket property that tells me "this interface is
a real one." Seriously, that's a bit of an issue, although Michael B's
proposed adjacency table for the ACP should fix it.

    Brian

---

From: John Strassner <[email-masked]>
Date: Fri, 25 Mar 2016 18:41:11 -0700

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]> wrote:

> I agree that autonomic node should have that self-advertisement ability,
> and autonomic management system should have this 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
>
> *From:* Anima [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, March 24, 2016 10:41 AM
> *Cc:* Duzongpeng; Laurent Ciavaglia; Sheng Jiang; [email-masked];
> Jéferson Campos Nobre

-- 
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Sat, 26 Mar 2016 03:08:38 +0000

Hi John

Thanks for your reply.

I know that you have been working on a policy model, In which intents are translated to low-level policies (with parameters) by a policy continuum.

I think it is valuable and should be considered in the development of ANIMA network.

However, it does not mean in ANIMA network, we can not operator ASA parameters directly using some simple mechanism.

IMO, which mechanism should be used is decided by the ASA, and it should be implementation-specific.

I means two mechanisms can both exist, and ASA can choose which to use according to its requirements and context.

If some ASAs need that the network operator to management directly, intent writer will need to know about that autonomic function, such as the purpose of the function, how to use, and parameters needed.

I agree that is kindly like a function call or an API, but it is network level. If you choose it is not an intent, while I think that perhaps some ASA need that, my suggestion is that we can choose another name.

Or we call it a certain kind of ANIMA intent, and declare that ANIMA intent has a larger scope than a pure intent.

Best Regards
Zongpeng Du

From: John Strassner [mailto:[email-masked]]
Sent: Saturday, March 26, 2016 9:05 AM
To: Duzongpeng; John Strassner
Cc: Michael Behringer (mbehring); [email-masked]; Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Hi Zongpeng,

Let me try to rephrase. It isn't a question of top-down or bottom-up, but rather, how complex the user model is. I am recommending a simple user model. This means that the user should not have to know in advance the list of specific autonomic functions that are present.

I do agree that we should start simple. One autonomic function is fine. However, I don't understand why you say that "it is not practical that an intent writer in ANIMA network do not know the information about autonomic functions in the autonomic domain". Intent shouldn't be a function call or an API. It should be expressed in a form natural to the intent writer, and then translated to a form that a device can consume.

regards,
John

On Fri, Mar 25, 2016 at 1:30 AM, Duzongpeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi, John

<jcs>

Best Regards
Zongpeng Du

Cc: Duzongpeng; [email-masked]<mailto:[email-masked]>; Laurent Ciavaglia; Jéferson Campos Nobre; Sheng Jiang

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Sat, 26 Mar 2016 03:46:11 +0000

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,

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>

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

<jcs2>

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,

regards,
John

<jcs>

Michael

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>
Agreed.
</jcs>

<jcs>

<jcs>

<jcs>
Absolutely agree!
</jcs>

 regards,
John

Michael

Hello, everyone

Best Regards
Zongpeng Du

--
regards,
John

--
regards,
John

--
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 17:15:32 +1300

> 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

---

From: John Strassner <[email-masked]>
Date: Sat, 26 Mar 2016 08:43:40 -0700

Hi Zongpeng,

I agree that both approaches can exist concurrently. This is a good
compromise.

regards,
John

On Fri, Mar 25, 2016 at 8:08 PM, Duzongpeng <[email-masked]> wrote:

> Hi John
>
>
>
> Thanks for your reply.
>
>
>
> I know that you have been working on a policy model, In which intents are
> translated to low-level policies (with parameters) by a policy continuum.
>
>
>
> However, it does not mean in ANIMA network, we can not operator ASA
> parameters directly using some simple mechanism.
>
>
>
> I means two mechanisms can both exist, and ASA can choose which to use
> according to its requirements and context.
>
>
>
> If some ASAs need that the network operator to management directly, intent
> writer will need to know about that autonomic function, such as the purpose
> of the function, how to use, and parameters needed.
>
>
>
> I agree that is kindly like a function call or an API, but it is network
> level. If you choose it is not an intent, while I think that perhaps some
> ASA need that, my suggestion is that we can choose another name.
>
>
>
> Or we call it a certain kind of ANIMA intent, and declare that ANIMA
> intent has a larger scope than a pure intent.
>
>
>
> Best Regards
>
> Zongpeng Du
>
>
>
> *Sent:* Saturday, March 26, 2016 9:05 AM
> *To:* Duzongpeng; John Strassner
> *Cc:* Michael Behringer (mbehring); [email-masked]; Laurent Ciavaglia;
> Jéferson Campos Nobre; Sheng Jiang
> functions in the autonomic domain". Intent shouldn't be a function call
> or an API. It should be expressed in a form natural to the intent writer,
> and then translated to a form that a device can consume.
>
>
>
> regards,
>
> John
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sat, 26 Mar 2016 08:54:01 -0700

> 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.
>

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 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.

>> 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.

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.
>
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Most catalogs that I have seen have very few details. They instead tell
> the user what services or products are available.
> > </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
> >
> “exceptions”. The AN story fills the “default” part very nicely, and *CIEs
> get that.
> > <jcs2>
> > Agreed!
> > </jcs2>
> >
> try to define exactly *what* intent allows and doesn’t allow, since we’ve
> > 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
> And if someone really puts into his Intent “node A: do this; node B: do the
> back and think whether they’re doing the right thing ☺
> > <jcs2>
> 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>
> [email-masked]<mailto:[email-masked]>> wrote:
> > John,
> >
> “exceptions”. The AN story fills the “default” part very nicely, and *CIEs
> get that.
> >
> try to define exactly *what* intent allows and doesn’t allow, since we’ve
> And if someone really puts into his Intent “node A: do this; node B: do the
> back and think whether they’re doing the right thing ☺
> >
> > <jcs>
> 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.
> >
> > 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]>>
> level, more along the line “do the right thing” ☺
> >
> > <jcs>
> per autonomic function. An Intent parser will validate overall correctness
> 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>
> >
> >
> [email-masked]<mailto:[email-masked]>> wrote:
> > Hi Zongpeng,
> >
> 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
> per autonomic function. An Intent parser will validate overall correctness
> 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.
> >
> contribute, I’m just struggling with priorities at the moment (as you can
> see by my relative silence over the past weeks).
> >
> > Michael
> >
> >
> >
> > Cc: Laurent Ciavaglia <[email-masked]<mailto:
> [email-masked]>>; Jéferson Campos Nobre <[email-masked]
> <mailto:[email-masked]>>; Sheng Jiang <[email-masked]<mailto:
> [email-masked]>>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Mar 2016 07:53:21 +1300

Hi John,
> 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.

> policy management component. I hope that ANIMA doesn't make the

Certainly, Intent needs a number of properties such as self-consistency
and stability that imply it is managed in some way.

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Mar 2016 16:21:16 -0400

If we want to flood the data, I would appreciate knowing whether RFC 
2334 is potentially useful.

Yours,
Joel

On 3/25/16 2:18 PM, Alexander Clemm (alex) wrote:
> *From:*Duzongpeng [mailto:[email-masked]]
> *Sent:* Friday, March 25, 2016 4:43 AM
> *To:* John Strassner <[email-masked]>; Alexander Clemm (alex)
> <[email-masked]>
> *Cc:* Michael Behringer (mbehring) <[email-masked]>; Laurent
> Ciavaglia <[email-masked]>; Sheng Jiang
> <[email-masked]>; [email-masked]; Jéferson Campos Nobre
> <[email-masked]>
> *Sent:* Thursday, March 24, 2016 11:41 AM
> *To:* Alexander Clemm (alex); John Strassner
> *Cc:* Michael Behringer (mbehring); Duzongpeng; Laurent Ciavaglia; Sheng
> Jiang; [email-masked] <mailto:[email-masked]>; Jéferson Campos Nobre
> I'm not sure I follow a couple of your points, please see
> inline...though in retrospect, perhaps this is merely a case of who the
> actor is (in my case, I am worried about the writer and user of intent,
> not how we build it).
>
> The only reason I can see for doing this is to enable collaboration
> and/or emergent behavior (in the AI sense). However, if you want
> emergent behavior from autonomic nodes, then each node that is part of
> that collaboration must interact. I don't think we know enough about
> this to support or prohibit such behavior, other than this places an
> extra requirement on the computational and reasoning abilities of the node.
>
> I agree that we can have every node in the autonomic domain have the
> same intent. Within my understanding, it can be a candidate solution.
>
> The advantage of the solution is simple. By using some synchronization
> mechanism, it makes all the node in the autonomic domain can work
> cooperatively.
>
> Another consideration is that when a new node join in the autonomic
> domain, perhaps it can receive the intent from its neighbor.
>
> I means Administrative Intent here, not a service intent. (Section 8 of
> https://tools.ietf.org/html/draft-du-anima-an-intent-03)
>
> should use roles as an indirection mechanism for scalability when
> working with Autonomic Domains.
>
> </jcs>
>
> [duzongpeng]
>
> When a user issues an intent, she/he should know the domain name. I mean
> an intent can contain the domain name as one of its element.
>
> <mailto:[email-masked]>] *On Behalf Of *Michael Behringer (mbehring)
> *To:* John Strassner <[email-masked] <mailto:[email-masked]>>
> Laurent Ciavaglia <[email-masked]
> <mailto:[email-masked]>>; Sheng Jiang
> <[email-masked] <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>; Jéferson Campos Nobre <[email-masked]
> <mailto:[email-masked]>>
> more “parameters”than “policy”, and I think we’ll just have to
> acknowledge that.
>
> <jcs>
>
>     two levels:
>     push more “parameters”than “policy”, and I think we’ll just have to
>     acknowledge that.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Mar 2016 09:42:25 +1300

Oh, I had completely forgotten that existed. At least, it should be mentioned
in the Appendix to GRASP. Were there implementations?

I have the impression that it's best suited to scenarios in which any node
is equally likely to originate an update; that isn't quite what we expect for
an AN scenario.

The algorithm looks quite similar to what DNCP does (after all, the DNCP authors
originally proposed a set of OSPF extensions, iirc.) Also quite similar to what
Michael B described. I'm sure we can learn from it.

Boy, that's a sad litany of dead companies in the author list: Bay Networks, Bellcore, Newbridge.

Regards
   Brian

On 27/03/2016 09:21, Joel M. Halpern wrote:
> If we want to flood the data, I would appreciate knowing whether RFC 2334 is potentially useful.
> 
> Yours,
> Joel
>

---

From: John Strassner <[email-masked]>
Date: Sat, 26 Mar 2016 22:12:58 -0700

Hi Brian

Sorry, I'm trying to picture in my head the user model that you
(and presumably Zongpeng) have.

> all relationships are peer-to-peer.

Sure, but **intent** is **not** self-forming.

> 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.

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?

> 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.

There may indeed be a new mode of communication required.
However, if intent is not standardized, how does this work?

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:

> >>> From: Anima [mailto:[email-masked]<mailto:
> [email-masked]>]
> >> On Behalf Of John Strassner
> *CIEs
> shouldn’t
> the
> view,
> *CIEs
> shouldn’t
> the
> view,
> >> Jéferson Campos Nobre <[email-masked]<mailto:[email-masked]
> >>;
> network,
> sets a
> nodes
> of
> friends
> push
> acknowledge
> correctness
> locally,
> >>> In this way, a function owner defines both the intent itself, and how
> it
> >> is consumed by his/her function.
> >>>
> >>> <jcs>
> what
> network,
> sets a
> nodes
> correctness
> locally,
> >>> In this way, a function owner defines both the intent itself, and how
> it
> >> is consumed by his/her function.
> >>>
> can
> >>> From: Anima [mailto:[email-masked]<mailto:
> [email-masked]>]
> >> On Behalf Of Duzongpeng
> with
> is

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Mar 2016 08:09:17 +1300

Hi John,

> (and presumably Zongpeng) have.

I believe we are closer to the same view than you might think...

> Sure, but **intent** is **not** self-forming.

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.)

> 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. Of course, the semantics of
intent must be well-defined, but it's an extra layer.

> those syntactical structures?

Agreed. We need a model, syntax and semantics.

> 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.

    Brian

---

From: "Natale, Bob" <[email-masked]>
Date: Sun, 27 Mar 2016 21:47:33 +0000

I do not see any conflict between the notions of default behavior and intent ... default settings inherent reflect intent ... it is the responsibility of the operator (I assert) to understand that intent before activating an entity on the network and its implications for downstream operations (when default behavior has to be restored for some reason or other) ... the intent reflected in default settings/behavior might very well, of course, deviate sharply from the operator's intent; hence, the need for clear understanding and preparations to deal with it (that could be reflected in the autonomic protocols themselves).

Apologies if the above is somewhat tangential to what is being discussed in the threat at this stage ... just wanted to record the general point.

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Sunday, March 27, 2016 3:09 PM
To: John Strassner <[email-masked]>
Cc: Laurent Ciavaglia <[email-masked]>; Duzongpeng <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; [email-masked]; Sheng Jiang <[email-masked]>
Subject: Re: [Anima] Does Autonomic network need some intervention beyond intent

Hi John,

On 27/03/2016 18:12, John Strassner wrote:
> Hi Brian
> 
> Sorry, I'm trying to picture in my head the user model that you (and 
> presumably Zongpeng) have.

> Sure, but **intent** is **not** self-forming.

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.)

> 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. Of course, the semantics of intent must be well-defined, but it's an extra layer.

> syntactical structures, and likely, different semantics associated 
> with those syntactical structures?

>> north/south communication and reduce the amount of centralized work. 
>> So there's a trade-off - more autonomic messaging means less 
>> north-south messaging.
> 

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.

    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
> 
>>>> 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.
>>>>
>>> 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.
>>
>>> 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.
>>> was used for compilation. There was, in fact, a separate 
>>> distribution mechanism (which I have also described), but that was 
>>> limited to "just" distribution.
>>>
>> 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
>>>
>>>>> parsing
>>>> 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
>>>> There are very few northbound APIs. That's what the operators that 
>>>> I
>> have
>>>> talked to want.
>>>>> </jcs>
>>>>>
>>>>> But, my understanding is that ANIMA network is a little different 
>>>>> from
>>>> SDN network.
>>>>>
>>>>> parsing
>>>>> I mean the ANIMA interface is perhaps something like “northbound + 
>>>>> part
>>>> of southbound”.
>>>>>
>>>>> Best Regards
>>>>> Zongpeng Du
>>>>>
>>>>>
>>>>> But I do not support that the intent writer should look every 
>>>>> detail in
>>>> the catalog.
>>>>> <jcs>
>>>>> The intent writer may mainly care about what they want, but how to 
>>>>> do
>> it
>>>>> This is one of the reasons why I would like to see capabilities 
>>>>> (and
>>>> needs) advertised.
>>>>> </jcs>
>>>>>
>>>>> ...
>>>> exposed to the network operator, and some of the Autonomic 
>>>> Functions
>> can be
>>>> There are very few northbound APIs. That's what the operators that 
>>>> I
>> have
>>>> talked to want.
>>>>>
>>>>> regards,
>>>>> John
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>> exposed to the network operator, and some of the Autonomic 
>>>> Functions
>> can be
>>>>> Perhaps in future, when the network nodes become more intelligent, 
>>>>> the
>>>> hidden part will increase.
>>>>>
>>>>>
>>>>> Best regards
>>>>> Zongpeng Du
>>>>>
>>>> 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>
>>>>>
>>>> Let’s NOT do selective flooding, unicast Intent to specific nodes, 
>>>> etc, because that would blur the boundary even worse.
>>>>> <jcs2>
>>>> 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>
>>>> other; node C: do the third” it is awkward enough for people to 
>>>> take a
>> step
>>>>> between the fabric and each autonomic function? I hope not, but 
>>>>> perhaps I'm misunderstanding you...
>>>>> < /jcs>
>>>>> 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>
>>>> but aligns very well with the way how things are organised. 
>>>> sent a few days
>> ago.
>>>>> 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 think we’re on the same page. Couple of points, top posting 
>>>>> here,
>>>> 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.
>>>>>
>>>> Let’s NOT do selective flooding, unicast Intent to specific nodes, 
>>>> etc, because that would blur the boundary even worse.
>>>>>
>>>> other; node C: do the third” it is awkward enough for people to 
>>>> take a
>> step
>>>>> between the fabric and each autonomic function? I hope not, but 
>>>>> perhaps I'm misunderstanding you...
>>>>> </jcs>
>>>>>
>>>>> section
>>>> for the fabric, and sections for the various functions. Seems a 
>>>> natural structure?!?
>>>>>
>>>> but aligns very well with the way how things are organised. 
>>>> sent a few days
>> ago.
>>>>> Cc: Duzongpeng 
>>>>> <[email-masked]<mailto:[email-masked]>>;
>>>> <[email-masked]<mailto:[email-masked]
>>>> ;
>>>> 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
>>>>> "only" policy </jcs>
>>>> high level, more along the line “do the right thing” ☺
>>>>>
>>>>> <jcs>
>>>>> types
>>>> 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
>>>>> to
>>>>> Sorry Michael, I don't follow here. What do you mean by 
>>>>> "parameters"?
>>>>> </jcs>
>>>>>
>>>>>
>>>>> sections
>>>> (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>
>>>>> between the fabric and each autonomic function? I hope not, but 
>>>>> perhaps I'm misunderstanding you...
>>>>> </jcs>
>>>>>
>>>>>
>>>>> I don't think that the intent writer should be cognizant of how 
>>>>> many or what types of autonomic functions are present.
>>>>> </jcs>
>>>>>
>>>>>
>>>>> they
>>>>> And hence, the "HAL 2000" scenario. :-) </jcs>
>>>>>
>>>>>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 29 Mar 2016 18:29:47 +0200

Hello,

> 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)...?

> 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...
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).

>   Of course, the semantics of

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.

> 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.
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...

Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 29 Mar 2016 18:30:00 +0200

Hello,

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 squared) 
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 networks. Intent is one way 
to inform the network what is expected.

Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 08:29:34 +1300

Hi Laurent, comments in line:
On 30/03/2016 05:29, Laurent Ciavaglia wrote:
> 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.

> 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

Agreed. Obviously the defaults must be conservative and fail-safe.

> 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.

> 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