Subject: [Anima] Anima Intent use cases and Key Points //RE: Intent sources and recipients [Re: Du & Jeferson: question about Yokohama]

From: Duzongpeng <[email-masked]>
Date: Fri, 9 Oct 2015 09:31:55 +0000

Dear All:

	As one of the authors of the draft https://tools.ietf.org/id/draft-du-anima-an-intent-01.txt, I want to share some working plans for comments.

	Although “intent” has been discussed a lot in the maillist, further consensus about the concept and definition of “intent” is needed.

	We plan to add some usecases to the draft for a better understanding of what we need for “intent” in Autonomic Network.

	The first two usecases:

	-Two examples of possible intent defined by the operator could be:
Autonomic Network (AN) of Operator A is composed of Autonomic Function Agents (AFA) such as load balancing (LB_AFA) and energy saving (ES_AFA). 
-Policy 1: Operator A wants to limit the proportion of links loaded over a certain threshold and thus defines a policy (Intent?) to activate load balancing if the load is superior to 0.6 on more than 30% of the links.
-Policy 2: Operator A now wants different load balancing policies per (technology, administrative, topology) domain. Let's consider a metropolitan network domain and a core network domain, or different LB policy for border routers than interior routers. For the metropolitan network domain, Operator A defines a policy to minimize the link load variance. For the core network domain, Operator A applies the previously defined policy (activate load balancing if the load is superior to 0.6 on more than 30% of the links).
How the AFAs receive, understand and react to the policy is to be defined. How the domain(s) are defined and recognized (if I am an AFA, how do I know i am part of domain x, y or z...?).

	The following four usecases are from me. IMO, the declarative logics can work well perhaps for most of the network policies. However, some use cases in building an autonomic network indeed need more than declarative logics. 
•	Usecase one: proposed by Brian in [Anima] Secret intent [was big pictures diagrams --- how bootstrap fits into signaling and discovery], Brian E Carpenter
	o	It has be agreed that “parameters to bootstrap” are needed, but whether called intent is uncertain.
	o	These parameters are different from normal “intent”, and are not declarative logics, but standardizing them is needed for autonomic network
•	Usecase two: Assuming we need a autonomic network to run and connect to Internet, an IP prefix is needed for the whole autonomic domain in the data plane
	o	In this case, we need devices in the autonomic domain can configure themselves after the human operator has notified the IP prefix for this autonomic network. (Configuring every device’s IP address manually is not considered a good way in autonomic network, and is not recommended here.)
	o	Whatever the way of getting its IP addresses for every device, the first step (i.e. notifying the IP prefix for this autonomic network) is always needed. However, it needs not to be a declarative logic, and is just a network level parameter.
•	Usecase three: configuring the routing protocol in the autonomic network, assuming it can be ISIS or OSPF.
	o	For a declarative logic, maybe it can just say “we need the network can routable” without giving a specific protocol, such as ISIS or OSPF
	o	However, making network can decide this autonomiclly brings more work for the devices but very little benefit, and the human operator would rather to assign one instead.
•	Usecase four: in the prefix management draft, draft-jiang-anima-prefix-management, it is suggested that the prefix length for the CSG, ASG, RSG (different roles in IPRAN) should be assigned as an “intent”
	o	For a declarative logic, perhaps this is not considered an intent (not that abstract), and it is perhaps considered needed for the network to learn knowledge and decide the prefix lengths autonomically.
	o	However, the realization of the above method is difficult, and hard to be suitable for all the network environments. On the contrary, for a specific network such as an IP RAN, assigning the prefix lengths is a straightforward way for  the human operator.

   So my suggestion is to accept that an intent should be declarative, but clarify that autonomic network needs more than that. If we can agree with these, perhaps we can work on this kind of use cases first without depending on what works out in SUPA (which needs time to complete). These network level parameters, whether called intent or not, are more likely only needed to be configured once, and rarely changed. Most of these parameters are for establishing network infrastructure, and little flexibility are needed. Meanwhile, these parameters do not need coordination with others parameters most of the times.

	We have talked about the usecases recently (attached below), and agree that the key points include at least the following:
-  Are there any configuration parameters of an anima network outside intents?
-  Are there different kinds of intents?
-  Who are the sources and recipients of the intent?
-  When/on which triggers are intents generated, updated?

Best Regards
Zongpeng Du

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, October 06, 2015 2:53 AM
To: Laurent Ciavaglia; duzongpeng; Jéferson Campos Nobre
Cc: Duzongpeng; Sheng Jiang
Subject: Intent sources and recipients [Re: Du & Jeferson: question about Yokohama]

Just picking on one topic (and I hope this can be input to the draft, since we shouldn't discuss too much off list):

>     -Some basic aspects that should eb clarified are: who are the 
> sources and recipients of the intent

It seems fairly clear to me that any autonomic node may be the recipient of intent.
Of course some items will only interest some ASAs, but the basic model for intent should be flooding.

The question of sources is more interesting, since I assume we expect only authorised nodes to send intent. How is that going to work?

    Brian

Hi, Laurent

Thanks for your reply. I agree with your ideas. If we did some typical use cases, I think even SUPA can cite them.

I agree in most of the cases, ANIMA intent and SUPA intent are overlapped, so surely we should have at least one use case to show that relationship, and fortunately you have provided some.

Best Regards
Zongpeng Du

--

在 2015-10-05 17:31:05，"Laurent Ciavaglia" <[email-masked]> 写道：
>Dear all,
>
>That's an interesting discussion and we should continue it and write down some of these aspects in a revision of the draft.
>
>I agree that the ANIMA Intent work should be "independent" from the SUPA work progress, however, if commonalities are identified we should also make sure both concepts / specifications converge harmoniously wherever possible.
>
>I agree also with the comments from Jéferson (on configuration, and types of intent...).
> 
>For the ANIMA intent, to continue on the thoughts exchanged:
>    -Indeed, Intent should not be considered as a monolithic block, the Intent will be "interpreted" by different entities in ANIMA networks, and the "level" of understanding of the intent will impact how the intent will be presented to this entity. So there should be "intermediate" mechanisms/functions that cater for the intent translation continuum across the heterogeneity (in policy capabilities) of the network entities. Also, intents will possibly overlap and this overlapping should be managed (e.g. avoid conflicts, resolve applicable policies in context...)
>    -Some basic aspects that should eb clarified are: who are the sources and recipients of the intent ; when/on which triggers are intents generated, updated...
>    -Starting with some typical examples is fine. This should allow us to remain pragmatic, and at the same time, we should extract from these use cases the essence of the intent (model, specifications, usages...) in order to design the right intent "object" for ANIMA.
>    -Two examples of possible intent defined by the operator could be:
>Autonomic Network (AN) of Operator A is composed of Autonomic Function Agents (AFA) such as load balancing (LB_AFA) and energy saving (ES_AFA).
>-Policy 1: Operator A wants to limit the proportion of links loaded over a certain threshold and thus defines a policy (Intent?) to activate load balancing if the load is superior to 0.6 on more than 30% of the links.
>-Policy 2: Operator A now wants different load balancing policies per (technology, administrative, topology) domain. Let's consider a metropolitan network domain and a core network domain, or different LB policy for border routers than interior routers. For the metropolitan network domain, Operator A defines a policy to minimize the link load variance. For the core network domain, Operator A applies the previously defined policy (activate load balancing if the load is superior to 0.6 on more than 30% of the links).
>How the AFAs receive, understand and react to the policy is to be defined. How the domain(s) are defined and recognized (if I am an AFA, how do I know i am part of domain x, y or z...?).
>
>I will put some of the above ideas into text for the draft and share it with you in the coming days.
>
>We would also have to talk about the content of the presentation in IETF94, in coordination with the request from the chairs.
>
>Best regards, Laurent.
>
>
>
>
>On 03/10/2015 19:11, duzongpeng wrote:
>
>Hi, Jéferson
>
>Thanks for your reply. I agree with your considerations.
>
>If the intent's definition in ANIMA can be extended and if ANIMA needs more than intent are the key points. To make them clear is helpful for the further work.
>
>Can we start with the use cases? Perhaps they can be treated as some "interim" intents compared to the pure intent.
>
>It is said that intent should be "abstract", but indeed the "abstract" is comparative. Different users of the network see different details of the network, and have different abstract levels, which has been discussed in NEMO.  
>
>To be "hierarchy" is s good way to get convergence. We can also think further according to this direction.
>
>Best Regards
>Zongpeng Du
>--
>
>
>在 2015-10-03 00:42:44，"Jéferson Campos Nobre"  写道：
>
>Hi Du.
>Answers below.
>
>
>
> The discussions in the maillist are helpful to clarify the concept of Anima Intent. However, I think we should not restrict the Anima intent to totally depending on what works out in SUPA. While on the other hand, I also agree with Anima Intent of course can reuse the works in SUPA if it is proved helpful in any usecase as Sheng has said.
>
>
>
>Agreed.
>
>
>
>The declarative logics can work well perhaps for most of the network policies. However, some use cases in building an autonomic network indeed need more than declarative logics.
>
>  *   Usecase one: proposed by Brian in [Anima] Secret intent [was big pictures diagrams --- how bootstrap fits into signaling and discovery], Brian E Carpenter
>     *   It has be agreed that “parameters to bootstrap” are needed, but whether called intent is uncertain.
>     *   These parameters are different from normal “intent”, and are not declarative logics, but standardizing them is needed for autonomic network
>  *   Usecase two: Assuming we need a autonomic network to run and connect to Internet, an IP prefix is needed for the whole autonomic domain in the data plane
>     *   In this case, we need devices in the autonomic domain can configure themselves after the human operator has notified the IP prefix for this autonomic network. (Configuring every device’s IP address manually is not considered a good way in autonomic network, and is not recommended here.)
>     *   Whatever the way of getting its IP addresses for every device, the first step (i.e. notifying the IP prefix for this autonomic network) is always needed. However, it needs not to be a declarative logic, and is just a network level parameter.
>
>
>
>I think there are 2 important questions here: 
>- Are there any configuration parameters of an anima network outside intents?
>-  Are there different kinds of intents?
>Despite the fact that there was some discussion on these question at Prague, I think there is no consensus.
>For me, a clear definition on the "hierarchy" of intents (or if there will be one) is really necessary.
>
>
>
> So my suggestion is to accept that an intent should be declarative, but clarify that autonomic network needs more than that. If we can agree with these, perhaps we can work on this kind of use cases first without depending on what works out in SUPA (which needs time to complete). 
>
>
>
>Agreed.
>
>
>Em qua, 30 de set de 2015 às 16:30, Brian E Carpenter  escreveu:
>
>
>So my suggestion is to accept that an intent should be declarative, but 
>clarify that autonomic network needs more than that. If we can agree 
>with these, perhaps we can work on this kind of use cases first without 
>depending on what works out in SUPA
>
>
>I strongly agree. Waiting for another WG is usually a bad idea, and 
>excessive formalism at an early design stage is also a bad idea.
>
>Regards
>  Brian
>
>On 30/09/2015 17:03, Duzongpeng wrote:
>
>Hi Jéferson, and Laurent:
>        I want to share some personal understanding about the anima intent, and try to get agreements on some basic ideas.
>         The discussions in the maillist are helpful to clarify the concept of Anima Intent. However, I think we should not restrict the Anima intent to totally depending on what works out in SUPA. While on the other hand, I also agree with Anima Intent of course can reuse the works in SUPA if it is proved helpful in any usecase as Sheng has said.
>         The declarative logics can work well perhaps for most of the network policies. However, some use cases in building an autonomic network indeed need more than declarative logics.
>
>  *   Usecase one: proposed by Brian in [Anima] Secret intent [was big pictures diagrams --- how bootstrap fits into signaling and discovery], Brian E Carpenter
>     *   It has be agreed that “parameters to bootstrap” are needed, but whether called intent is uncertain.
>     *   These parameters are different from normal “intent”, and are not declarative logics, but standardizing them is needed for autonomic network
>  *   Usecase two: Assuming we need a autonomic network to run and connect to Internet, an IP prefix is needed for the whole autonomic domain in the data plane
>     *   In this case, we need devices in the autonomic domain can configure themselves after the human operator has notified the IP prefix for this autonomic network. (Configuring every device’s IP address manually is not considered a good way in autonomic network, and is not recommended here.)
>     *   Whatever the way of getting its IP addresses for every device, the first step (i.e. notifying the IP prefix for this autonomic network) is always needed. However, it needs not to be a declarative logic, and is just a network level parameter.
>  *   Usecase three: configuring the routing protocol in the autonomic network, assuming it can be ISIS or OSPF.
>     *   For a declarative logic, maybe it can just say “we need the network can routable” without giving a specific protocol, such as ISIS or OSPF
>     *   However, making network can decide this autonomiclly brings more work for the devices but very little benefit, and the human operator would rather to assign one instead.
>  *   Usecase four: in the prefix management draft, draft-jiang-anima-prefix-management, it is suggested that the prefix length for the CSG, ASG, RSG (different roles in IPRAN) should be assigned as an “intent”
>     *   For a declarative logic, perhaps this is not considered an intent (not that abstract), and it is perhaps considered needed for the network to learn knowledge and decide the prefix lengths autonomically.
>     *   However, the realization of the above method is difficult, and hard to be suitable for all the network environments. On the contrary, for a specific network such as an IP RAN, assigning the prefix lengths is a straightforward way for  the human operator.
>
>         So my suggestion is to accept that an intent should be declarative, but clarify that autonomic network needs more than that. If we can agree with these, perhaps we can work on this kind of use cases first without depending on what works out in SUPA (which needs time to complete). These network level parameters, whether called intent or not, are more likely only needed to be configured once, and rarely changed. Most of these parameters are for establishing network infrastructure, and little flexibility are needed. Meanwhile, these parameters do not need coordination with others parameters most of the times.
>
>
>
>Best Regards
>Zongpeng Du

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 9 Oct 2015 14:58:27 -0400

Apologies if I am missing something obvious.  This was prompted by 
Zongpeng Du's note, but is not specific to that.

I have seen several messages refering to load balancing, and to turning 
on load balancing.
I do not know what people expect from autonomic enabling of load 
balancing (or disabling?)  I wonder if people in this working group even 
mean the same thing.

One use of the term "load balancing" in general refers to redirection 
traffic to different end servers, so as to distribute server load.  This 
is normally done with explicit load balancers.  There are many types. 
It is normally an internal service specifically enabled / configured / 
requested by the owner of the end service.
I presume that is now what is meant here.

Another use is traffic distribution across roughly equal links.  This is 
frequently done by IP routing (ECMP) or layer 2 forwarding (LAG or 
multi-chassis LAG.)  I have trouble conceiving of a situation where one 
would autonomously turn such a behavior on or off.  At L3, it is usually 
on by default, and does the right thing.  At L2, it is normally 
configured because L2 does not traditionally use routing protocols with 
metrics.  Newer techniques enable the same automatic use as for L3.

And a third use is when human beings examine the traffic behavior in a 
network, and adjust metrics or other traffic steering techniques to 
better distribute the load.  While this is something that folks have 
been and are automating, that use usually centralized due to the need 
for an omniscient view to do the job right.

So when Anima talks about Load Balancing, what do we mean?

Thank you,
Joel

---

From: Duzongpeng <[email-masked]>
Date: Sat, 10 Oct 2015 02:16:17 +0000

Hi Joel:

Thanks for the comment. I want to introduce some background information and try to explain the reasons.

Within my understanding, ANIMA at this stage has not discussed too specific devices, such as explicit load balancers, and are mainly talking about the general devices like a router. Also, ANIMA mainly cares about the distributed network elements.

Cited from the working group Description:

Autonomic networking refers to the self-managing characteristics
(configuration, protection, healing, and optimization) of distributed 
network elements, adapting to unpredictable changes while hiding 
intrinsic complexity from operators and users.

So I guess that the use case is talking about "traffic distribution across roughly equal links".
Of course, it can work without Autonomic Functions.
However, in autonomic network, we need the network to be able to change the policies according to various network situations to become more intelligent. The distributed network elements should be able to take action according to the knowledge and information that it obtains, while human intervention is as little as possible. 

Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Saturday, October 10, 2015 2:58 AM
To: Anima WG
Cc: Jéferson Campos Nobre; Sheng Jiang
Subject: Re: [Anima] Anima Intent use cases and Key Points -- Load Balancing

Apologies if I am missing something obvious.  This was prompted by Zongpeng Du's note, but is not specific to that.

I have seen several messages refering to load balancing, and to turning on load balancing.
I do not know what people expect from autonomic enabling of load balancing (or disabling?)  I wonder if people in this working group even mean the same thing.

One use of the term "load balancing" in general refers to redirection traffic to different end servers, so as to distribute server load.  This is normally done with explicit load balancers.  There are many types. 
It is normally an internal service specifically enabled / configured / requested by the owner of the end service.
I presume that is now what is meant here.

Another use is traffic distribution across roughly equal links.  This is frequently done by IP routing (ECMP) or layer 2 forwarding (LAG or multi-chassis LAG.)  I have trouble conceiving of a situation where one would autonomously turn such a behavior on or off.  At L3, it is usually on by default, and does the right thing.  At L2, it is normally configured because L2 does not traditionally use routing protocols with metrics.  Newer techniques enable the same automatic use as for L3.

And a third use is when human beings examine the traffic behavior in a network, and adjust metrics or other traffic steering techniques to better distribute the load.  While this is something that folks have been and are automating, that use usually centralized due to the need for an omniscient view to do the job right.

Thank you,
Joel

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