Subject: [Anima] Another use case for Intent: "Freeze network enrolment"

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

Maybe we should combine two threads here. I think there is a perfect use case for Intent I  mentioned in another mail, which would be even applicable to what we do today: 

"Freeze network enrolment". 

Since any node can be a proxy node for bootstrap, it makes perfect sense to flood this to all nodes. 

Local override possible via traditional config / netconf / etc. 

No parameters needed. Can't get any simpler. 

Michael

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 24 March 2016 05:53
> To: John Strassner <[email-masked]>; Duzongpeng
> <[email-masked]>
> Cc: Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre
> <[email-masked]>; [email-masked]; Michael Behringer (mbehring)
> <[email-masked]>; Sheng Jiang <[email-masked]>
> Subject: Re: [Anima] Does Autonomic network need some intervention
> beyond intent
> 
> On 24/03/2016 16:49, John Strassner wrote:
> > 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.
> >
> > Surely we could pick a more appropriate example?
> 
> By all means describe other use cases and what sort of intent they need.
> 
>     Brian
> >
> >
> > regards,
> > John
> >
> > On Wed, Mar 16, 2016 at 5:41 AM, Duzongpeng
> <[email-masked]> wrote:
> >
> >> 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,
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> [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]
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> In this way, a function owner defines both the intent itself, and how
> >> it is consumed by his/her function.
> >>
> >>
> >>
> >> [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]
> >>
> >>
> >>
> >> In other words: Let’s not be too prescriptive, and hope that folks
> >> will do more or less reasonable things.
> >>
> >>
> >>
> >> [duzongpeng]Agree.[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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> *From:* Anima [mailto:[email-masked]
> >> <[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
> >>
> >>
> >>
> >>          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
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/anima
> >>
> >>
> >
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/anima
> >

---

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

> No parameters needed. Can't get any simpler. 

Right, but that one sure sounds like a partial update. The same would apply
to any other form of emergency signal.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 25 Mar 2016 13:40:01 +0000

> Sent: 24 March 2016 20:33
> To: Michael Behringer (mbehring) <[email-masked]>; John Strassner
> <[email-masked]>; Duzongpeng <[email-masked]>
> <[email-masked]>; [email-masked]; Sheng Jiang
> <[email-masked]>
> Subject: Re: Another use case for Intent: "Freeze network enrolment"
> 
> > Maybe we should combine two threads here. I think there is a perfect use
> case for Intent I  mentioned in another mail, which would be even applicable
> to what we do today:
> >

Sorry - can you expand? I'm not sure I understand what you're trying to say...
Michael

---

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

> Sorry - can you expand? I'm not sure I understand what you're trying to say...

I just thought that if the NOC wants to send out some sort of urgent instruction
to all nodes, it is by its nature a partial update of Intent. Of course a
partial update can be achieved by sending everything. That's a trade-off of
resource vs complexity, I suppose.

    Brian

---

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

> I just thought that if the NOC wants to send out some sort of urgent
> instruction to all nodes, it is by its nature a partial update of Intent. Of course
> a partial update can be achieved by sending everything. That's a trade-off of

Anything *can* be partial. My claim is that if Intent really is a high level policy, it should be so stable over time that the optimisation to support partial updates just isn't required. 

In my proposal on "content distribution" (https://mailarchive.ietf.org/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nDA08) I suggest a content type; I suggest to start with only one content type supported ("Intent version 0") and get experience with that. If it turns out that we need to slice it, we could define new content types, potentially much more granular, so that we could later support effectively a partial update. If we do this job well, the distribution protocol doesn't need to change at all. 

So my proposal is really: Let's start as simple as possible, but leave space to grow if we need to. 

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 11:38:48 -0400

The notion of distributing all intents as a single blob seems like a 
really bad model.  Policy always decomposes into pieces.  Some of those 
pieces are related.  I think that assuming that the total policy 
(intent) is small is asking for trouble.

This is also why I worry a bit about flooding to everything.

Yours,
Joel

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Mar 2016 15:50:59 +0000

Thanks Joel, I think we agree that *if* Intent can become big, and / or *if* it changes frequently, we need to divide and conquer. 

If however Intent is "high level", it should *not* change frequently. And I think we probably also agree that if an update is required say once a month, we *can* flood, and deal with it in one blob. (right?) 

So the real question is: What will Intent look like? Possibly we should go back to the use cases, and see what Intent for such a use case could look like. 

Michael

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 29 March 2016 17:39
> To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter
> <[email-masked]>; John Strassner <[email-masked]>;
> Duzongpeng <[email-masked]>
> Subject: Re: [Anima] Another use case for Intent: "Freeze network
> enrolment"
> 
> The notion of distributing all intents as a single blob seems like a really bad
> model.  Policy always decomposes into pieces.  Some of those pieces are
> related.  I think that assuming that the total policy
> >> instruction to all nodes, it is by its nature a partial update of
> >> Intent. Of course a partial update can be achieved by sending
> >> everything. That's a trade-off of resource vs complexity, I suppose.
> >
> > Anything *can* be partial. My claim is that if Intent really is a high level
> policy, it should be so stable over time that the optimisation to support
> partial updates just isn't required.
> >
> > In my proposal on "content distribution"
> (https://mailarchive.ietf.org/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nD
> A08) I suggest a content type; I suggest to start with only one content type
> supported ("Intent version 0") and get experience with that. If it turns out
> that we need to slice it, we could define new content types, potentially much
> more granular, so that we could later support effectively a partial update. If
> we do this job well, the distribution protocol doesn't need to change at all.
> >

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 29 Mar 2016 17:52:23 +0200

Michael,

It seems to me that "Freeze network enrollment" is a valid declarative 
form of policy (intent), yet it seems to be a counter-example to the 
argument of long-lasting intent, i.e. the operator will want to 
roll-back to "normal" behavior as soon as the issue that raised the 
"freeze" intent creation is cleared...
(I am not saying that the case is not a good one to investigate).

Am I over-/mis-interpreting?

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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 12:01:33 -0400

I can buy the low change rate.  In part because if we find that flooding 
is awkward, it is easy enough to add a new mechanism later.

But I find the assumption that being high level will somehow make 
intents small to be very unlikely.

Yours,
Joel

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Mar 2016 16:34:45 +0000

When I say “freeze” I mean: All the nodes that the operator expected to join, have joined; the next ones will come in 6 months. Until then, I want to disable the enrolment function.
Obviously, it *could* be understood as: for today, there are no more installations of new devices expected; tomorrow at 9 I expect an installation, so I unfreeze the network, once that device has enrolled I freeze again until 10, when the next one it expected. That would not be the right thing.
I guess that’s exactly the same for all examples... It depends how you use them.
Michael

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 29 March 2016 17:52
To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter <[email-masked]>; John Strassner <[email-masked]>; Duzongpeng <[email-masked]>
Cc: Laurent Ciavaglia <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; [email-masked]; Sheng Jiang <[email-masked]>
Subject: Re: Another use case for Intent: "Freeze network enrolment"

Michael,

It seems to me that "Freeze network enrollment" is a valid declarative form of policy (intent), yet it seems to be a counter-example to the argument of long-lasting intent, i.e. the operator will want to roll-back to "normal" behavior as soon as the issue that raised the "freeze" intent creation is cleared...
(I am not saying that the case is not a good one to investigate).

Best regards, Laurent.

Michael

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

To: John Strassner <[email-masked]><mailto:[email-masked]>; Duzongpeng

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

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

<[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Behringer (mbehring)

<[email-masked]><mailto:[email-masked]>; Sheng Jiang <[email-masked]><mailto:[email-masked]>

beyond intent

autonomic intent.

case?

the taxi driver.

    Brian

regards,

John

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

Hi, Michael,

now.

Autonomic intent.

discussed later.

Best

Regards

Zongpeng Du

*To:* Duzongpeng; [email-masked]<mailto:[email-masked]>

beyond intent

Hi Zongpeng,

two

levels:

concerns.

[duzongpeng]

you mention

that.

Intent like “node

[duzongpeng]

Michael

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

beyond intent

Hello, everyone

beyond intents.

         For example, in the

enterprise network.

some other words.

ACP

configured once

Best Regards

Zongpeng Du

Anima mailing list

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

Anima mailing list

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

--

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 Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Mar 2016 16:35:48 +0000

> Sent: 29 March 2016 18:02
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: Laurent Ciavaglia <[email-masked]>; [email-masked]
> I can buy the low change rate.  In part because if we find that flooding is
> awkward, it is easy enough to add a new mechanism later.
> 
> But I find the assumption that being high level will somehow make intents
> small to be very unlikely.

Do you have an example? 

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Mar 2016 12:45:42 -0400

There are two drivers here.

First, when I look at the history of configs, they started small, and 
then got large, evne when the number of interfaces and neighbors did not 
grow that fast (and the neighbor count went up much more than we expected.)

Second, I look at the growth of topics on which people have policy.

The result is that I would strongly prefer a design which coped with a a 
large number of roles, ASAs, policy parameters, and other aspects.

No, I can't prove it.  But looking at the hsitory of protocol design, I 
find that we have made a mess when we assume things will be small, and 
generally done reasonably when we assume things will grow beyond our 
expectations.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Mar 2016 14:52:55 -0400

see inline

Michael Behringer (mbehring) <[email-masked]> wrote:
    > When I say “freeze” I mean: All the nodes that the operator expected
    > to join, have joined; the next ones will come in 6 months. Until then,
    > I want to disable the enrolment function.

Okay, so tell the registrar to stop approving new nodes.

Does that need to be network-wide?
If you really mean that you want to turn off the new node join helpers,
then let's be clear about that.

Maybe the registrar should emit an intent that says, "Willing to join nodes"
when "unfrozen", and that is what causes nodes that can perform the helper
function to enable it.

{it would be great if you'd edit the trail of the message to remove the
content which isn't relevant. Google and the mail archive would thank you}

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

---

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

> So my proposal is really: Let's start as simple as possible, but leave space to grow if we need to. 

Without disrespect to the subsequent arguments, I think this is a key
point. At the moment we're designing the ANI, not the Intent system,
so what I'm looking for in this discussion is the features that the ANI
has to support - which seem to be
(a) ability to distribute the complete Intent to all nodes
(b) ability to distribute partial Intent to all (interested) nodes later on

BTW I put "interested" in parenthesis because it seems dangerous to
assume that a node's interests don't change. As ASAs start or stop
in a given node, its interest in Intent will change. So unless we
construct a quite elaborate pub/sub system, flooding is needed,
even for partial intent. That's what GRASP supports, of course.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 12:20:38 +1300

On 30/03/2016 04:38, Joel M. Halpern wrote:
> The notion of distributing all intents as a single blob seems like a really bad model.  Policy always decomposes into pieces. 
> Some of those pieces are related.  I think that assuming that the total policy (intent) is small is asking for trouble.
> 

There's a technical issue there, which is that GRASP flooding uses
multicast UDP (what else could it reasonably use, anyway?). So if
the chunk to be flooded gets too big, we would have to chop it up.

    Brian

>> Anything *can* be partial. My claim is that if Intent really is a high level policy, it should be so stable over time that the
>> optimisation to support partial updates just isn't required.
>>
>> In my proposal on "content distribution" (https://mailarchive.ietf.org/arch/msg/anima/KNIglx9abDMEejwEZu9hE4nDA08) I suggest a
>> content type; I suggest to start with only one content type supported ("Intent version 0") and get experience with that. If it
>> turns out that we need to slice it, we could define new content types, potentially much more granular, so that we could later
>> support effectively a partial update. If we do this job well, the distribution protocol doesn't need to change at all.
>>
> .

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 30 Mar 2016 01:54:58 +0200

Thanks Michael (B.), I was wrong in my understanding.

Laurent.

On 29/03/2016 18:34, EXT Michael Behringer (mbehring) wrote:
> Obviously, it **could** be understood as: for today, there are no more 
> installations of new devices expected; tomorrow at 9 I expect an 
> installation, so I unfreeze the network, once that device has enrolled 
> I freeze again until 10, when the next one it expected. That would not 
> be the right thing.
>
> *From:*Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* 29 March 2016 17:52
> *To:* Michael Behringer (mbehring) <[email-masked]>; Brian E 
> Carpenter <[email-masked]>; John Strassner 
> *Cc:* Laurent Ciavaglia <[email-masked]>; Jéferson Campos 
> Nobre <[email-masked]>; [email-masked]; Sheng Jiang 
> <[email-masked]>
> *Subject:* Re: Another use case for Intent: "Freeze network enrolment"
>
> Michael,
>
>     Maybe we should combine two threads here. I think there is a
>     perfect use case for Intent I  mentioned in another mail, which
>     would be even applicable to what we do today:
>
>         <[email-masked]> <mailto:[email-masked]>
>
>         Cc: Laurent Ciavaglia <[email-masked]>
>         <mailto:[email-masked]>; Jéferson Campos Nobre
>
>         <[email-masked]> <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>; Michael Behringer
>         (mbehring)
>
>         <[email-masked]> <mailto:[email-masked]>; Sheng Jiang
>         <[email-masked]> <mailto:[email-masked]>
>
>         <[email-masked]> <mailto:[email-masked]> wrote:
>
>                 Hi, Michael,
>
>                 *To:* Duzongpeng; [email-masked] <mailto:[email-masked]>
>
>                 <[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]>
>
>                 [email-masked] <mailto:[email-masked]>
>
>             [email-masked] <mailto:[email-masked]>
>

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 30 Mar 2016 02:12:47 +0200

Brian,

> (b) ability to distribute partial Intent to all (interested) nodes later on

The perimeter of the ANI is arbitrary / matter of convention. We decide 
something for ANI in ANIMA, (many) others have defined their own scope 
for their autonomic architectures.
There are several surveys on that compare functionality of autonomic 
network architectures. The fact that some functionality are found in 
every approaches for more than a decade could be interpreted as a good hint.

In order to understand the features the ANI has to support, we need to 
understand what could/should be factorized in the ANI.
At least for me, this means to understand a bit more how the "intent" 
system would/could work end-to-end.

Also, RFC 7575, section 3.8 Common Autonomic Networking Infrastructure 
mentions:
"This Autonomic Networking Infrastructure may contain common control and 
management functions such as messaging, service discovery, negotiation, 
Intent distribution, self-monitoring, and diagnostics, etc.  A common 
approach to define and manage Intent is also required.
All the components around the "Autonomic Service Agents" should be 
common components, such that the Autonomic Service Agents do not have to 
replicate common tasks individually.

Thanks, Laurent.

---

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

> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 29 March 2016 20:53
> To: [email-masked]

Yes, that's another way, but then you have the proxy function running everywhere. 
 
> If you really mean that you want to turn off the new node join helpers, then
> let's be clear about that.

Both are options. I was looking for a simple example of what network wide Intent could look like, and this example is something we can understand with today's ANI (as opposed to taking into account autonomic functions that don't exist yet). 

> when "unfrozen", and that is what causes nodes that can perform the helper

Here is where we have to be careful: Intent (in my understanding) comes from an admin, not from a device in the network. Not saying it can't, but we need to be clear about it if we allow it. 
 
The challenge is that we have many choices and options. 

> content which isn't relevant. Google and the mail archive would thank you}

I normally do. May overlook sometimes. 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2016 20:49:17 -0400

> the chunk to be flooded gets too big, we would have to chop it up.

This is why I really think that the URL for the Intent (maybe using the rfc6920
ni:// URLs) should be flooded, and let the nodes ask for the things they
need.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Mar 2016 21:23:18 -0400

If we just passed around URLs (or URIs, or  UR?), how would the ASAs 
know which ones they needed to fetch?

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Mar 2016 15:35:36 +1300

On 31/03/2016 14:23, Joel M. Halpern wrote:
> If we just passed around URLs (or URIs, or  UR?), how would the ASAs know which ones they needed to fetch?

And I'm not sure why we'd want to add a protocol.

What could be done is to flood a new version announcement (with version number
plus checksum, for example) that would prompt recipients to do an explicit
unicast synchronization of the whole thing. But of course that loses the
benefit of flooding and caching prior to the ASA needing the Intent.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Mar 2016 09:37:12 -0400

> which ones they needed to fetch?

They wouldn't know, so they'd have to retrieve all of the ones they didn't
have so that they would have a "complete" set of Intents.

But, we'd be flooding the URNs (~60 bytes), rather than the potentially
multiple packet-sized-each contents.  It's just flood by reference rather
than value.

And ASAs wouldn't need to get Intents they already had.

[If I had to design this from scratch, and we didn't have trickle flooding in
GRASP already, I'd use ICP (RFC2186)]