Subject: [Anima] Intent Discussion

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 7 Apr 2016 11:14:40 +0000

Yesterday Joel, John, Toerless, Jeferson, Jason and I met to discuss about Intent, and see where we agree / disagree. Below some notes for remote attendees, to chime in. Obviously, nothing is cast in stone, these are still personal views, just aggregated in a form that we are all more or less happy with. Maybe that helps the discussion.

Michael

--

Intent Discussion 
- some draft consensus between Joel, John, Toerless, Jeferson, Jason, Michael

Naming: 
- High level policy = Intent
- Any messaging to enforce that, signalling of parameters resulting from it, 
  etc may be required but is NOT Intent

Intent one single file? 
- Intent may come from different entry points
- should not enforce a single file. (but it may be initially)
- but shouldn't be just lots of separate statements either. 

Fragmenting Intent
- however we express Intent, we don't want to require that Intent MUST be 
  able to be de-composed into its atomic bits with a fixed size limit
  --> we must not require that atomic bit MUST fit into a packet.
- some form of fragmenting an Intent file is ok
  + could be done through using TCP (or similar)
  + could be done by fragmenting Intent into individual parts

Updating / removing Intent
- Intent doesn't have a mandatory expiration date
- if no longer required / desired, remove or update Intent. 
- it's ok to have a *statement* to remove a *statement*. 

Flooded? 
- good enough for now to flood.
  BUT: as long as we have a more granular way to "upgrade to" later. 

Conflict resolution? 
- device needs to deal with conflict and react predictably. 
- device may not be able to resolve locally. 
- but the conflict may need to be resolved centrally --> needs a feedback loop. 
  (we don't specify where those feedback loops are going - several posibilities)

"Translating" Intent
- Does Intent have to be "translated" from a high level policy to something 
  more lower level before it gets distributed? 
- Ex from John: "Platinum customer" - always best service. 
  But I shouldn't map everything (ex: FTP) into an EF queue. 
- might require to translate to an intermediate Intent format. 
- this tranlation should probably not happen on the devices.
  this translation could/should happen centrally;
- more discussion needed on this point.

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Apr 2016 16:15:58 +0200

Dear Michael, all,

Thanks for sharing the summary, it is appreciated to be able to stay 
connected with on-site discussion ;)

 >Re: Conflict resolution?
 >  (we don't specify where those feedback loops are going - several 
possibilities)

This is a perfect introduction for my talk in ANIMA session today:
     16:35 - 16:45 Autonomic Functions Coordination - 
draft-ciavaglia-anima-coordination

Thanks, Laurent.

On 07/04/2016 13:14, EXT Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 

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: Thu, 07 Apr 2016 12:03:40 -0400

> Michael

Thanks for the notes.

    > + could be done by fragmenting Intent into individual parts

We are building an ACP that supports our entire suite of IP(v6) protocols.
Fragmentation/segmentation, caching are already protocols that we have.

Intents are going to be signed objects of some kind.
(I favour JOSE, but xmldsig would be fine as well, or even S/MIME if someone
has a good argument for that).

I don't see any reason we should worry if Intents fit into a packet.
So, can we stop?

    > - Intent doesn't have a mandatory expiration date

Can I amend this to: An Intent doesn't have to have a finite expiration date?
Couldn't an Intent apply until "Condition X" is met?

    > - it's ok to have a *statement* to remove a *statement*.

Yes, I agree strongly.

Consider a base Intent that says that the network should move as much traffic
as possible.  (Imagine that in the future there were peering arrangements at
IXs so that we had automatic bidding in the way that the electrical market
works in some parts of the world)

Imagine an Intent that is issued on Tuesday that says:
        "Limit committed traffic to an aggregate of less than PIPE X"
        (Inception Date: Thursday 23:59
        Expiry Date: Monday 00:00)

The reason to issue this Intent is because of planned maintenance on the
weekend which will cause pipes Y and Z to become unstable.

The above Intent would amend the original base intent for a period of time,
and then it would expire.

    > (we don't specify where those feedback loops are going - several posibilities)

We'll have an ASA for that.  Seriously.

    > more lower level before it gets distributed?

We'll have an ASA for that too.
Maybe it requires that a VM be spun up with some vendor specific software
that translates intents to CLI commands (I'm familiar with JUNOS Space..);
but whatever works.

    > this translation could/should happen centrally;

I think that each device may well observe the Intent, and may well ask their
oracle if they are compliant.

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 7 Apr 2016 18:06:37 +0000

inline...  (expressing my views, not the groups, just to be clear)

[...]
> (I favour JOSE, but xmldsig would be fine as well, or even S/MIME if
> someone has a good argument for that).
> 

I think this is what we're trying to say. It doesn't make sense to try to align Intent with packets. :-) 

> Couldn't an Intent apply until "Condition X" is met?

It *could*. 

> Consider a base Intent that says that the network should move as much
> traffic as possible.  (Imagine that in the future there were peering
> arrangements at IXs so that we had automatic bidding in the way that the
> electrical market works in some parts of the world)
> 

We could do this. 
 
> posibilities)

I think you mean an "autonomic function" (which consists of ASAs on some/all nodes). The point is a single device can't figure it out. So you needs some way to "coordinate" - do a feedback loop, etc. Yes, this could be implemented in the form of an autonomic function. 

> that translates intents to CLI commands (I'm familiar with JUNOS Space..);

right. 
 
> oracle if they are compliant.

That's one way to do the above (some coordination). 

Michael

---

From: John Strassner <[email-masked]>
Date: Fri, 8 Apr 2016 09:46:37 -0700

Hi Michael,

(snipping)...

> Intent one single file?
...
> I don't see any reason we should worry if Intents fit into a packet.

I think we all agree here...

> Couldn't an Intent apply until "Condition X" is met?

Agreed

...

posibilities)

> We'll have an ASA for that.  Seriously.

I would think that:

   a) there will be multiple ASAs for this
   b) there will be local (e.g., per-domain) and global (e.g., spanning
domains)
       sources of conflict detection and resolution

> that translates intents to CLI commands (I'm familiar with JUNOS Space..);

IMHO, intent is scoped by the tuple {domain, context, role}. So, we will
likely
have **multiple** ASAs for this.

> oracle if they are compliant.

Agreed

On Thu, Apr 7, 2016 at 9:03 AM, Michael Richardson <[email-masked]>
wrote:

> traffic

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Apr 2016 16:58:30 +1200

On 07/04/2016 23:14, Michael Behringer (mbehring) wrote:
...
>   --> we must not require that atomic bit MUST fit into a packet.

I understand that, but we should note that this significantly
complicates flooding of Intent to all nodes.

...
> - good enough for now to flood.

The only straightforward flooding mechanism we have now *does* assume
that the atomic bits fit in a packet.

>   BUT: as long as we have a more granular way to "upgrade to" later.

Actually the granular mechanism is there too but *doesn't* assume
that the atomic bits fit in a packet.

I think we need to think about draft-liu-anima-grasp-distribution
as a potential requirements document in this area.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 12 Apr 2016 07:43:59 +0000

In my mind, we'd use GRASP to signal amongst nodes just the current version of Intent (or if it comes packaged for example for a set of autonomic functions, that Intent set). 

Then, use TFTP (for example) to actually transmit the file. This way we get reliability, re-transmission, fragmenting, etc, all for free, and don't have to worry about that in GRASP. 

Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month! 

Michael

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 12 April 2016 06:59
> To: Michael Behringer (mbehring) <[email-masked]>; anima
> <[email-masked]>
> Subject: Re: [Anima] Intent Discussion
> 
> I understand that, but we should note that this significantly complicates
> flooding of Intent to all nodes.
> 
> ...
> > Flooded?
> Actually the granular mechanism is there too but *doesn't* assume that the
> atomic bits fit in a packet.
>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 12 Apr 2016 10:49:33 +0200

Hello,

> Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month!
It's not so much the intent's lifetime that matters, than the frequency 
at which the user (or the policy management system) 
creates/updates/deletes intents.

Laurent.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 12 Apr 2016 09:15:45 +0000

Agree. Also that, in my mind, is long lived; again, to me Intent is "high level policy". That doesn't change frequently.

I still suspect at the bottom of this discussion is a different understanding of what Intent actually is....

Michael

From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: 12 April 2016 10:50
To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter <[email-masked]>; anima <[email-masked]>
Subject: Re: [Anima] Intent Discussion

Hello,

Noting that, if Intent is really relatively long lived, the signalling happens all the time, actual transfer only if there is a new version. To me: Order of once a month!
It's not so much the intent's lifetime that matters, than the frequency at which the user (or the policy management system) creates/updates/deletes intents.

Laurent.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Apr 2016 09:38:09 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > In my mind, we'd use GRASP to signal amongst nodes just the current
    > version of Intent (or if it comes packaged for example for a set of
    > autonomic functions, that Intent set).

Yes, what I've been saying.

    > Then, use TFTP (for example) to actually transmit the file. This way we
    > get reliability, re-transmission, fragmenting, etc, all for free, and
    > don't have to worry about that in GRASP.

Well, not TFTP, it has horrible congestion properties.
If HTTP is too heavy for some reason, use CoAP.

    > Noting that, if Intent is really relatively long lived, the signalling
    > happens all the time, actual transfer only if there is a new
    > version. To me: Order of once a month!

Agreed.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 12 Apr 2016 13:47:12 +0000

> From: Michael Richardson [mailto:[email-masked]]
> Sent: 12 April 2016 15:38
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: Brian E Carpenter <[email-masked]>; anima
> <[email-masked]>

replace TFTP with "a protocol that has reliability, fragmentation, etc". No strong views from my side.

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Apr 2016 11:33:03 -0400

One of the points that was discussed off-line in BA was that some folks 
in this discussion treat all the information exchanged by Anima as 
intent, and other folks treat Intent as one subset of the several 
varieties of information exchanged by Anima.

It is pretty clear that for many of the policy control goals, there has 
to be frequent exchange of information.  That information is not the 
human generated intents, but it is important information.

Another aspect that makes me nervous is this assumption of stability. 
In one sense, it seems to follow naturally (human's don't change their 
busienss goals all that often).  However, as the scope of an Anima 
system becomes larger, and as people realize they can change the system 
goals more frequently, I expect that the policy aspects will change more 
frequently.  I even expect to see automated systems producing new policy 
goals.  (Whether those systems are within Anima or above it is irrelevant.)

Yours,
Joel

On 4/12/16 5:15 AM, Michael Behringer (mbehring) wrote:
> Agree. Also that, in my mind, is long lived; again, to me Intent is
> “high level policy”. That doesn’t change frequently.
>
> I still suspect at the bottom of this discussion is a different
> understanding of what Intent actually is....
>
> Michael
>
> *From:*Anima [mailto:[email-masked]] *On Behalf Of *Laurent
> Ciavaglia
> *Sent:* 12 April 2016 10:50
> *To:* Michael Behringer (mbehring) <[email-masked]>; Brian E
> Carpenter <[email-masked]>; anima <[email-masked]>
> *Subject:* Re: [Anima] Intent Discussion
>
> Hello,
>
>     Noting that, if Intent is really relatively long lived, the
>     signalling happens all the time, actual transfer only if there is a
>     new version. To me: Order of once a month!
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Apr 2016 13:54:44 -0400

> varieties of information exchanged by Anima.

I think that you are observing a real discord, and I think that we need some
terminology to get a handle on things, but I also think it's premature.

My impression is that we are very much in bootstrap/bottom-up mode here, and
I think it's okay to remain in that mode for awhile longer.

    > change their busienss goals all that often).  However, as the scope of
    > an Anima system becomes larger, and as people realize they can change
    > the system goals more frequently, I expect that the policy aspects will
    > change more frequently.  I even expect to see automated systems
    > producing new policy goals.  (Whether those systems are within Anima or
    > above it is irrelevant.)

One could argue that the automated system is producing new policy statements
(We both avoid using the word Intent here) for the network based upon some
higher-level Intent.

But, for other networks, these "policy statements" are produced by humans.

(mcr licks the 15-year old wounds from the "policy WG"...)

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 12 Apr 2016 22:12:41 +0200

> I think it's okay to remain in that mode for awhile longer.

Yes... maybe... (for the "premature" / "that mode thing").
I think it is worth/instructive to have those discussions on "intent" / 
other "non-chartered" items now and to continue them. Maybe not only (or 
not at all) in the ANIMA mailing list...
NMRG would be glad to host such discussions and interactions. There has 
been a series of NMRG meetings on autonomic networking prior to the UCAN 
BoF and ANIMA WG creation. We could easily re-activate them. (see my 
upcoming post on the NMRG list).
Another perspective is that ANIMA charter "ends" in Q4-2016, so it's 
seems timely to engage into future ((potential) items discussions and 
orientations.
It doesn't mean that the chartered items/WG documents will not progress 
(and such discussions should not hinder their development), I see these 
activities complementary to each other.

Best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2016 14:41:21 +1200

> In my mind, we'd use GRASP to signal amongst nodes just the current version of Intent (or if it comes packaged for example for a set of autonomic functions, that Intent set). 

So you'd flood the version info and unicast the content? Well, it's certainly
simpler than worrying about reliable multicast.

> Then, use TFTP (for example) to actually transmit the file. This way we get reliability, re-transmission, fragmenting, etc, all for free, and don't have to worry about that in GRASP. 

Actually, GRASP Synchronize over TCP should work fine. There's no arbitrary size limit.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 13 Apr 2016 15:43:39 +0000

> version of Intent (or if it comes packaged for example for a set of autonomic
> functions, that Intent set).
> 

Yes. See https://mailarchive.ietf.org/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nDA08 for my original proposal. 
 
> > Then, use TFTP (for example) to actually transmit the file. This way we get
> reliability, re-transmission, fragmenting, etc, all for free, and don't have to
> worry about that in GRASP.
> 

Again, no strong view on protocol; we should pick the easiest one that gives us reliability. (Always thinking also constrained devices)

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2016 08:47:51 +1200

On 13/04/2016 03:33, Joel M. Halpern wrote:
> One of the points that was discussed off-line in BA was that some folks in this discussion treat all the information exchanged
> by Anima as intent, and other folks treat Intent as one subset of the several varieties of information exchanged by Anima.

Yes. That's why we really to need to address the question posed by
draft-liu-anima-grasp-distribution - do we need a general infrastructure
mechanism for information distribution? (Then there's a second question
whether it is anima-specific such as a GRASP extension, or an existing
mechanism running over the ACP.)

That is really a separate discussion from Intent.

   Brian

> 
> It is pretty clear that for many of the policy control goals, there has to be frequent exchange of information.  That
> information is not the human generated intents, but it is important information.
> 
> Another aspect that makes me nervous is this assumption of stability. In one sense, it seems to follow naturally (human's don't
> change their busienss goals all that often).  However, as the scope of an Anima system becomes larger, and as people realize
> they can change the system goals more frequently, I expect that the policy aspects will change more frequently.  I even expect
> to see automated systems producing new policy goals.  (Whether those systems are within Anima or above it is irrelevant.)
> 
> Yours,
> Joel
>