Subject: [Anima] ANIMA intent discussion

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 30 Mar 2016 18:10:18 +0200

Dear all,

Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this 
morning, trying to clarify some points and progress toward a common 
understanding.

We used a small, partial set of questions and examples in support.

Below you may find a summary for your information. Comments and further 
interactions are most welcome.

Thanks,
Michael, Zongpeng, Pierre and Laurent.
---

--- Questions
1-Who writes intents?
2-How many intents?
3-How many domains?
4-What are the intent levels/hierarchy?
5-Where/by what is intent processed/compiled?
6-Flooding: what are the requirements? Propagation among who? How 
distributed? How frequent? -> if many “overlapping” intents, (partial) 
updates may become frequent.
7-How is intent understood by node/ASA? -> model, dictionary...
8-Can an ASA write an intent for another ASA? What about coordination 
or knowledge writing/receiving intents? Are these functions ASAs/other 
things..?

--- Intent examples
A-Do the right thing
B-Freeze network enrollment
C-Arrange VM guest distribution so that (CPU) utilization is < 70%
D-Assign prefixes to RAN nodes
E-Protect premium users traffic
F-Maximize energy savings

--- Discussion
1) Who writes intents?
    Laurent's view:
     Intents are issued by a management function. Can be human / via 
BSS/OSS.
    Michael's view:
     Origin of intent is "non-technical". i.e., registrar doesn't issue 
intent.
_Discussion:_ how to set the cursor on non-technical? In examples D or 
E, the intent writer has some rough knowledge/understanding of technical 
aspects of a network (wireless and address aspects for example D ; 
protection/restoration and traffic engineering for example E).
_Consensus:_ Intent is originated by human/at OSS level, NOT by a 
network device / function. (of course Intent can be ingested / inputted 
on a specific device)

2) How many intents?
    Laurent's view:
     There may be different ones, like "freeze network", "optimize 
energy savings", cf examples. All are valid and concurrent.
     Can we wrap that into one file?
     How do we share that?

_Discussion__:_
     We cannot define Intent too precisely today.
     But we can define where Intent is coming from and how to distribute 
it.

     Can Intent have targets?
         - Ex: an intent for traffic engineering and an intent for 
energy consumption optimization may need specific (same or different) 
targets. the functions could have different objectives per set of targets.
         - Ex: two network segments, core and metro. Then intent should 
be able to say "on core: optimize on availability"; on access: "optimize 
on energy saving."
         - Therefore we need scopes.

      How do you define "target"?
         - Is a role enough?
         - Pierre: Should be more than role. Example: Metro and core. 
Need to distinguish between different metro networks for example.
         - Michael: If we have sub-domains, and define intent per 
sub-domain, would that do?
         - Laurent: a combination of roles and (sub-)domain(s) should be 
able to cover most cases.

_Consensus:_ a combination of roles and (sub-)domain(s) should be able 
to cover most cases.

8) Can an ASA write an intent?
     Pierre: Example is the coordination function: that function could 
send out intent directly to modify the behavior of a group of ASAs.
      Multiple ASAs could do conflicting things. The coordination 
function must resolve that. Should it issue/modify intent itself?
     Laurent: q1: should it output something in the form of an intent? 
q2: should the coordination function update intent?
     Michael: Isn't it that the behavior of the coordination function 
must also be resolved by a human originated intent? i.e. the conflicting 
functions inform the operator via a feedback loop and the operator 
adjust the intents.
     Laurent: This is possible / complementary. In once case, the 
operator is the one closing the control loop / changing the behaviors 
via intent updates. With a coordination function, part/all of that 
process could be automated/driven by the machine (the coordination 
function closes the control loop, in the control range allowed by the 
operator). There may be intermediate steps where unforeseen conflicts 
will be resolved. This is run time conflict resolution.
     Michael: Do we foresee a case where networks resolve conflicts 
without human control?
     Laurent: this is possible (has been demonstrated in some projects). 
We should allow for both approaches to work, possibly in a phased approach.

     When unforeseen conflicts arise, ASAs can signal to each other, but 
they will not issue Intent themselves.

_Consensus:_ Cannot say today if other functions can/are allowed to 
issue intent / intent updates. Functions/ASAs may have to *signal* or 
*message* somehow, but that this isn’t considered     intent yet.
     For further study: try to design the intent system so that both 
approaches (feedback loop, coordination) are possible. More 
investigation/analysis needed.

3) How many domains?
Naming issue: "domain" by Laurent is a high level concept; could be 
understood as a DNS domain name. Needs to be clear what we're talking 
about.
     With domain-name based intent (i.e., access.att.net) and roles 
(e.g, access devices) we should be able to express what we need for now. 
Not 100% clear for now.
     Two types of domains: (administrative, technology) domains defined 
(a priori) by the operator e.g. RAN, MAN, WAN. and the domain of 
application of a policy i.e. resolving the policy defines a set of 
target entities to which teh policy applies, this is the domain of 
application of the given policy.

_Consensus:_ Need to clarify wording to avoid confusion.

4)What are the intent levels/hierarchy?
     Related to policy based manamegent model: business level, service 
level, network level, device level, etc. So far in ANIMA we consider 
only two levels: User and ASA.
     Do we need a service level? e.g, VPN.
     Can we express different levels with using roles? So a role could 
be very specific (route reflector), or service related (e.g., VPN 
head-end)?
     But then we may need to nest roles?!
     Maybe we need "business" "service" "network (ASA)" level?

_Consensus:_ to be further discussed.

Questions 5, 6, 7 were not discussed due to lack of time.
---

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2016 22:11:06 -0400

These are good questions, thank you for assembling them.

> 1) Who writes intents?

Let me answer with a question: can marketing/sales-people write intents?
(I suspect we all know the answer should be no, but probably we should be
explici that Intents are technical statements.
But consider if an Intent can be written like, "optimize network to provide a
minimum bandwidth of X between points Y and Z"...)

Based upon that devices do not write intent, I think that "freeze network" is
not a well specified Intent. Instead I suggest that the Intent should read
something like:
    "The network will start growing at INITIAL-DATE, and
    will continue until either condition-X or FINAL-DATE"

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 31 Mar 2016 08:27:43 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 31 March 2016 04:11
> To: anima <[email-masked]>
> Subject: Re: [Anima] ANIMA intent discussion
> 
> 

Strongly disagree :-)  : If we do a good job, then a business person CAN and SHOULD issue Intent. You should NOT require a technical person to do this. 

That of course means in the end we need a suitable user interface.
 
And I see as well that on the way to this goal, before functions are really self-managing, we still need to give more technical guidance. But I'd see that as an intermediate step. 

>     will continue until either condition-X or FINAL-DATE"

That is definitely an option. Depends how flexible we want to make it. 

Michael

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 31 Mar 2016 10:36:27 +0200

I think that the person should at least be knowledgeable enough to 
understand (the implications of) what he/she is asking for.

-m

Le 31/03/2016 10:27, EXT Michael Behringer (mbehring) a écrit :
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 31 Mar 2016 08:40:32 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Martin
> Vigoureux
> Sent: 31 March 2016 10:36
> To: [email-masked]

Agree. But a good user interface can solve that / help with it. 

Michael

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 31 Mar 2016 11:13:22 +0200

> Agree. But a good user interface can solve that / help with it.

I agree with both of you ;)
Using some sort of catalog (suggested by John S. few days ago on the 
list) is a first step: capabilities of the "network" (ASAs, other 
things...) are expressed, aggregated (maybe annotated) in a common 
format understandable to the user (technical and/or non-technical). This 
sets a first bound on what the user can or cannot do.
Other aspects to consider: (properties of) language (or other means) 
offered to the user to write the intents, ontologies / common lexicon, 
safeguards on values/syntax checking, etc.
a full project on its own! let's go for a BoF ;)

Laurent.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 31 Mar 2016 11:22:41 +0200

Please see inline with [lc][/lc]
> Strongly disagree :-)  : If we do a good job, then a business person CAN and SHOULD issue Intent. You should NOT require a technical person to do this.

[lc]: I think it should be possible for a business person to write 
intent. however, (maybe) this is out of scope of ANIMA, and even maybe 
of IETF (?).
Something we could try to achieve in ANIMA is to define an intent system 
that NOC engineers could use, and define interfaces or recommendations 
for upper layers (business).
[/lc]

---

From: Duzongpeng <[email-masked]>
Date: Fri, 1 Apr 2016 02:39:02 +0000

Hi Laurent, Michael, Martin

         I agree that different kinds of users can issue intent, but their intents can be different, and with different purposes.

The network operator will be able to issue intent very detailed, and perhaps non-technical people will have more general intents.

Non-technical people will mainly care about how to use the network, for their specific services.

The network operator will care about the network infrastructure, to make sure the network can provide proper services to uplayer users.

I think we can firstly working on some Administrative intent just like we have firstly worked on some infrastructure functions in ANIMA.

I support that it needs to be done about way to writing intent, especially for the uplayer users, and it is very important.

John perhaps can help because he has already done some work on this.

In conclusion, it turns to be very flexible in the definition of intent (too many ways exist), and needs a huge amount of work.

My suggestion is that we need to figure out some steps on this, not to start too many things in parallel in ANIMA.

Best Regards
Zongpeng Du

From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: Thursday, March 31, 2016 5:13 PM
To: EXT Michael Behringer (mbehring); Martin Vigoureux; [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] ANIMA intent discussion

-----Original Message-----

Vigoureux

To: [email-masked]<mailto:[email-masked]>

Michael

I agree with both of you ;)
Using some sort of catalog (suggested by John S. few days ago on the list) is a first step: capabilities of the "network" (ASAs, other things...) are expressed, aggregated (maybe annotated) in a common format understandable to the user (technical and/or non-technical). This sets a first bound on what the user can or cannot do.
Other aspects to consider: (properties of) language (or other means) offered to the user to write the intents, ontologies / common lexicon, safeguards on values/syntax checking, etc.
a full project on its own! let's go for a BoF ;)

Laurent.

---

From: Duzongpeng <[email-masked]>
Date: Fri, 1 Apr 2016 03:56:08 +0000

Hi, Michael, Laurent, Pierre

         About whether ASA can issue intent, according to my understanding, intent should be issued by human by default.

         But in the discussion, I realize that we may have two kinds of intent.

         The first kind of intents are the ones issued from humans, perhaps not only from one person.

         And another is the intent after the coordination. They are the intent influencing the node directly. I mean coordination does not need to happen on every node, and they only need the result.

         This is an interesting model. If we can find some examples, I think perhaps some ASAs may choose to use intent like this, and ASA can issue the second kind of intent.

         Again, if someone think these are just some signals or messages, we can give it another name, such as “network-level policy” or “intent after coordination”.

Best Regards
Zongpeng Du

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: Thursday, March 31, 2016 12:10 AM
To: anima
Cc: Michael Behringer; Pierre Peloso; Duzongpeng; Laurent Ciavaglia
Subject: ANIMA intent discussion

Dear all,

Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this morning, trying to clarify some points and progress toward a common understanding.

Below you may find a summary for your information. Comments and further interactions are most welcome.

Thanks,

--- Questions
1-Who writes intents?
2-How many intents?
3-How many domains?
4-What are the intent levels/hierarchy?
5-Where/by what is intent processed/compiled?
6-Flooding: what are the requirements?
Propagation among who? How distributed? How frequent? -> if many “overlapping” intents, (partial) updates may become frequent.
7-How is intent understood by node/ASA? -> model, dictionary...
8-Can an ASA write an intent for another ASA?
What about coordination or knowledge writing/receiving intents? Are these functions ASAs/other things..?

--- Intent examples
A-Do the right thing

--- Discussion
1) Who writes intents?
   Laurent's view:
    Intents are issued by a management function. Can be human / via BSS/OSS.
   Michael's view:
    Origin of intent is "non-technical". i.e., registrar doesn't issue intent.
   Discussion: how to set the cursor on non-technical? In examples D or E, the intent writer has some rough knowledge/understanding of technical aspects of a network (wireless and address aspects for example D ; protection/restoration and traffic engineering for example E).
   Consensus: Intent is originated by human/at OSS level, NOT by a network device / function. (of course Intent can be ingested / inputted on a specific device)

2) How many intents?
   Laurent's view:
    There may be different ones, like "freeze network", "optimize energy savings", cf examples. All are valid and concurrent.
    Can we wrap that into one file?
    How do we share that?

    Discussion:
    We cannot define Intent too precisely today.
    But we can define where Intent is coming from and how to distribute it.

    Can Intent have targets?
        - Ex: an intent for traffic engineering and an intent for energy consumption optimization may need specific (same or different) targets. the functions could have different objectives per set of targets.
        - Ex: two network segments, core and metro. Then intent should be able to say "on core: optimize on availability"; on access: "optimize on energy saving."
        - Therefore we need scopes.

     How do you define "target"?
        - Is a role enough?
        - Pierre: Should be more than role. Example: Metro and core. Need to distinguish between different metro networks for example.
        - Michael: If we have sub-domains, and define intent per sub-domain, would that do?
        - Laurent: a combination of roles and (sub-)domain(s) should be able to cover most cases.

    Consensus: a combination of roles and (sub-)domain(s) should be able to cover most cases.

8) Can an ASA write an intent?
    Pierre: Example is the coordination function: that function could send out intent directly to modify the behavior of a group of ASAs.
     Multiple ASAs could do conflicting things. The coordination function must resolve that. Should it issue/modify intent itself?
    Laurent: q1: should it output something in the form of an intent? q2: should the coordination function update intent?
    Michael: Isn't it that the behavior of the coordination function must also be resolved by a human originated intent? i.e. the conflicting functions inform the operator via a feedback loop and the operator adjust the intents.
    Laurent: This is possible / complementary. In once case, the operator is the one closing the control loop / changing the behaviors via intent updates. With a coordination function, part/all of that process could be automated/driven by the machine (the coordination function closes the control loop, in the control range allowed by the operator). There may be intermediate steps where unforeseen conflicts will be resolved. This is run time conflict resolution.
    Michael: Do we foresee a case where networks resolve conflicts without human control?
    Laurent: this is possible (has been demonstrated in some projects). We should allow for both approaches to work, possibly in a phased approach.

    When unforeseen conflicts arise, ASAs can signal to each other, but they will not issue Intent themselves.

    Consensus: Cannot say today if other functions can/are allowed to issue intent / intent updates. Functions/ASAs may have to *signal* or *message* somehow, but that this isn’t considered     intent yet.
    For further study: try to design the intent system so that both approaches (feedback loop, coordination) are possible. More investigation/analysis needed.

3) How many domains?
    Naming issue: "domain" by Laurent is a high level concept; could be understood as a DNS domain name. Needs to be clear what we're talking about.
    With domain-name based intent (i.e., access.att.net) and roles (e.g, access devices) we should be able to express what we need for now. Not 100% clear for now.
    Two types of domains: (administrative, technology) domains defined (a priori) by the operator e.g. RAN, MAN, WAN. and the domain of application of a policy i.e. resolving the policy defines a set of target entities to which teh policy applies, this is the domain of application of the given policy.

    Consensus: Need to clarify wording to avoid confusion.

4) What are the intent levels/hierarchy?
    Related to policy based manamegent model: business level, service level, network level, device level, etc. So far in ANIMA we consider only two levels: User and ASA.
    Do we need a service level? e.g, VPN.
    Can we express different levels with using roles? So a role could be very specific (route reflector), or service related (e.g., VPN head-end)?
    But then we may need to nest roles?!
    Maybe we need "business" "service" "network (ASA)" level?

    Consensus: to be further discussed.