Subject: [Anima] Content Distribution

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

Just writing down how I see Intent distribution as a whole process, for discussion. And, I want to abstract from distributing "Intent" to distributing "content", where "Intent" is one type only. 

Starting point: a node is booted; say it has no Intent initially; 
   $content_type = "Intent"
   $my_version = 0;
   it consults the AN adjacency table (see section 5 of the reference model draft).
   it has n neighbours in the same domain --> n ACP connections. 

Run every t sec, or when I just received new content: 
- For each neighbour in the adjacency table with an ACP connection:  
   - send $content_type; $my_version
   - receive $content_type; $remote _version
   - if  $my_version = $remote _version
           exit;
   - if  $my_version < $remote_ version
           pull $content (unicast from that neighbour)
   - if  $my _version > $remote_version
           push $content (unicast to that neighbour)

All of the above happens in the ANI; ASAs are not involved in this operation. 
Probably GRASP does the version comparison; not sure about the file transfer.

The $content_type allows us to use the same mechanism to flood other things; this gives us a lot of flexibility to distribute other content types later on; and, if we find out that we *really* need to separate Intent for different autonomic functions, we could then say $content_type = "Intent for function a" for example (of course this is schematic only; we may want sub-fields). 

The Intent is stored as a file. it is that file that gets re-distributed. This file is locally validated (signature) and parsed, and then passed to the ASAs. And a portion of Intent will affect the ANI itself. 

How far off am I with this thinking? I think this is very simple and robust. 

draft-liu-anima-grasp-distribution-01 has I think the same fundamental thinking, but specified a lot of things that are not needed, IMO: 
- I do not think we need selective distribution (2.2)
- I do not think we need incremental distribution (2.3)
- 3.1 is a bit redundant, if we assume distribution in the ACP. I would rather state
  as above "to all ACP neighbors", then we have the boundary detection implicit. 
- I think the above algorithm avoids loops automatically. 
- I don't think we need selective flooding (3.4)

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Mar 2016 05:12:53 -0400

If we want to go with that approach (and it is one reasonable approach), 
I would presume it would be worth considering a minor optimization:

store the version you received from the neighbor,
any time you receive something new, see if any neighbor is interested in 
it,
if they are interested, and it is newer than what they have, push it to 
them.

This improves convergence.  It has the cost that an entity may receive 
the same intent from several neighbors.  At which point I think one 
could make the time based check a much lower rate backup mechanism.

Yours,
Joel

On 3/25/16 4:55 AM, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

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

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 25 March 2016 10:13
> To: Michael Behringer (mbehring) <[email-masked]>; [email-masked]
> Subject: Re: [Anima] Content Distribution
> 
> If we want to go with that approach (and it is one reasonable approach), I
> would presume it would be worth considering a minor optimization:
> 
> store the version you received from the neighbor, any time you receive
> something new, see if any neighbor is interested in it, if they are interested,
> and it is newer than what they have, push it to them.

Thanks Joel. I think the proposed algorithm actually does that. There is the sub-clause "or when I just received new Intent", which does mostly what you describe, except in this algorithm you'd still exchange the version number before pushing the file; that could be removed; yes, optimisations are possible of course. 

My main point is: This algorithm would take care of flooding through the domain, loop avoidance, etc, while being very simple. 
 
Thanks for the fast feedback! :-) 
Michael

> This improves convergence.  It has the cost that an entity may receive the
> same intent from several neighbors.  At which point I think one could make
> the time based check a much lower rate backup mechanism.
> 
> Yours,
> Joel
> 
> > Just writing down how I see Intent distribution as a whole process, for
> discussion. And, I want to abstract from distributing "Intent" to distributing
> "content", where "Intent" is one type only.
> >
> > The $content_type allows us to use the same mechanism to flood other
> things; this gives us a lot of flexibility to distribute other content types later
> on; and, if we find out that we *really* need to separate Intent for different
> autonomic functions, we could then say $content_type = "Intent for function
> a" for example (of course this is schematic only; we may want sub-fields).
> >
> > The Intent is stored as a file. it is that file that gets re-distributed. This file is
> locally validated (signature) and parsed, and then passed to the ASAs. And a
> portion of Intent will affect the ANI itself.
> >
> > draft-liu-anima-grasp-distribution-01 has I think the same fundamental
> thinking, but specified a lot of things that are not needed, IMO:

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 25 Mar 2016 23:43:49 +0100

Dear Michael, all,

Thanks for the nice example.
I now understand much better your intent ;) with "flooding".
I am fine with "unicast from/to that neighbor", and this solves my 
concerns/misunderstanding on that aspect (intent file distribution).
Your proposal seems to work fine to have all nodes sharing a same content.

So let's say that all nodes have a copy of the intent file.
My follow-up question relates to your conception of what happens next...
If the intent file contains all the intent policies entered by the 
operator, then it will be up to the nodes and/or ASAs to process the 
policies and act accordingly.
This is a strong assumption which implies that nodes/ASAs know how to 
interpret the content of the intent policies, which part shall be 
processed, how to resolve conflicts, how to coordinate with other 
nodes/ASAs impacted by the intent policies, etc...

I am not saying that this is not feasible, neither to be investigated 
(and maybe finally the way to adopt), but I have the following issues in 
mind:
-this approach seems to imply a replication of the capability to 
process/interpret intent policy in all nodes / ASAs, while it might be 
capability that is factorized at some (TBD) level.
-beyond the simple distribution mechanism (which is fine), this approach 
seems to move the complexity into nodes/ASAs for the processing of 
intent without indicating/considering the policy hierarchy and how 
translation is achieved.
-this approach seems to make it difficult to "create" / manipulate the 
mapping between the different levels of the policy continuum, e.g. 
referring to John example " one could imagine that a single Service 
intent would need multiple Autonomic Functions to be implemented", how 
the nodes/ASAs will know / coordinate wrt. the services they contribute to.

I think John also pointed to some interrogations in replies to Alex 
which are relevant here.

In conclusion:
-Ok with the mechanism proposed for content distribution.
-We need to dig more into the whole picture to assess if we are on the 
right track. I am not suggesting that your example would solve the above 
issues, but that investigating these issues might change how a intent is 
conceived, process, where/by whom and the corresponding design for ANIMA 
components, interactions, protocols.

Thanks, 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: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 14:41:59 +1300

>    it has n neighbours in the same domain --> n ACP connections.

They may be connections in the routing protocol, but they aren't connections
in the general sense, as far as I can see.

>    - send $content_type; $my_version

How is that different from link-local multicast to ALL_GRASP_NEIGHBOR_6 ?
(That is, I think this is simply GRASP flooding with a loop count of 1.)

>    - receive $content_type; $remote _version

So are you asking each neighbor to send you a unicast, or are
you simply assuming that they will flood at the same frequency?

>            pull $content (unicast from that neighbour)

OK, that's standard synchronization.

>            push $content (unicast to that neighbour)

We have no mechanism for that. You can flood it out or you can
wait to be asked. But anyway, if all nodes execute the same algorithm
at the same frequency, you don't need to push the content; the neighbor
will be asking for it soon enough.

> All of the above happens in the ANI; ASAs are not involved in this operation.

If you want to use GRASP, there will be ad hoc ASAs and objectives that exist
only for this purpose.

> Probably GRASP does the version comparison; 

Nope, that's exactly what the ad hoc ASA would do. It would in fact just
be the container for the above logic (except for the push, unless we add
a protocol feature, which is of course possible). Of course, it's an ASA
that is provided as part of the ANI (like those for enrollment).

> not sure about the file transfer.

If the file can be sent by TCP there's no problem that I can see; it will be
a separate thread anyway. If it really needs something more complex, that
would have to be explicit code in the ad hoc ASA. That's not a problem
either except more code to write.

> - I do not think we need selective distribution (2.2)

I don't know yet. But I don't think it's a decision we have to take yet.
Maybe there's one objective called "Intent". Maybe there are multiple
objectives called things like "Intent.General", "Intent.PrefixManager",
"Intent.MyStupidIdea". Your idea that $content_type is a parameter is
exactly right, IMHO. That allows for selective distribution later, if
we need it.

> - I do not think we need incremental distribution (2.3)

Again, I don't know yet, but it's a lot simpler if we don't.

>   as above "to all ACP neighbors", then we have the boundary detection implicit.

It's implicit anyway if we use GRASP discovery. It can't discover anything
outside the AN.

> - I think the above algorithm avoids loops automatically. 

I agree. It's probably not immune to a bad actor that keeps incrementing
the version number, however.

> - I don't think we need selective flooding (3.4)

And again, I don't know yet, but it's a lot simpler if we don't.

    Brian