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

From: John Strassner <[email-masked]>
Date: Fri, 1 Apr 2016 17:05:00 -0700

Hi all,

>> 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.

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

I have a hard time imagining a "big" intent statement. I think that
the **results** of a single intent could affect a lot of nodes (e.g., as
in my utilization example), and hence the results could be big, but
intent itself should not be large.

That being said, I do agree with Joel. Intent is not like writing a script.
Intent is a collection of high-level statements. Each of these
statements could translate into multiple lower-level statements (as in
the policy continuum), and this translation could be done several
times before the intent is transformed into a form that a device can
consume. So, the **total** set of policy instructions **will** be large.

> 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?)

I do agree that intent should not change frequently. I could definitely live
with constrained flooding, though I still prefer a simple message queue
(e.g., RabbitMQ) because of a key point:

   Why do we think that every autonomic node would be interested
   in intent, let alone be able to process it?

I do not think that we should "blobify" (sorry, I'm jet-lagged) intent.
Intent itself will almost certainly be small. Now, when we start
translating that to a form devices can consume, I think that we will
end up with a large number of small sets of commands. There
could be some utility in sending a blob of related commands to a
domain, or a targeted set of nodes, but I think that this is an
optimization problem, not a first-order architecture problem.

> 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.

It depends on what the goal is here. If the goal is to ensure that the
ANI can handle intent, I don't think that we need to know the precise
form of intent - we simply need to know its requirements. That's what
I thought we were talking about.

regards,
John

On Tue, Mar 29, 2016 at 8:50 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> 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
>
>
> > -----Original Message-----
> > 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]>
> > Cc: Laurent Ciavaglia <[email-masked]>; Jéferson Campos
> Nobre
> > <[email-masked]>; [email-masked]; Sheng Jiang
> > <[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
> > (intent) is small is asking for trouble.
> >
> > This is also why I worry a bit about flooding to everything.
> >
> > Yours,
> > Joel
> >
> > On 3/29/16 4:58 AM, Michael Behringer (mbehring) wrote:
> > >> 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.
> > >
> > > 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.
> > >
> > > So my proposal is really: Let's start as simple as possible, but leave
> space to
> > grow if we need to.
> > >
> > > Michael
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/anima
> > >
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Apr 2016 13:43:07 +1300

>    in intent, let alone be able to process it?

I suggest that there will be items of Intent that really do apply
to every single autonomic node and even to every single ASA.
The "maintenance window" one that Michael suggested is an example,
and power-saving vs performance* is another.

Other items that might be specific to ASAs have the flavour of being
configuration thresholds, and maybe shouldn't be called Intent at all.
It doesn't matter though - if they have to be distributed, we need a
mechanism to do so, whatever we call them.

"Freeze network enrolment" is an interesting case, because at first
sight, it's necessary and sufficient to send it to all bootstrap
proxies; nodes that are not proxies don't need it. But then if the
network partitions, a node might decide to become a new proxy. So
the "freeze" Intent needs to be cached in that node in advance, before
anyone knew it would be needed. So selective blobs of Intent might
be a bad idea.

...
> I thought we were talking about.

Indeed. It would be good to condense this discussion into those requirements.

Rgds
   Brian

* e.g., parameterised as 0..10 where 0 means always maximise power saving
and 10 means always maximise performance.

   Brian

---

From: John Strassner <[email-masked]>
Date: Fri, 1 Apr 2016 19:23:13 -0700

> 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.

This wasn't obvious to me. I can think of multiple meanings:

   1) temporarily stop enrollment because the operations
       staff has determined that continued enrollment will
       likely do something bad
   2) stop enrollment immediately because an event was
       received having those semantics

For me, the key point of intent is that it does not necessarily mean
"THOU SHALT DO THE FOLLOWING". Rather, I think of this as what is
traditionally called in policy management theory a "goal policy". As such,
it means that the system should try and achieve that goal (without
specifying the algorithmic steps to do so), and hence, most "goal policies"
expand into a fairly complex set of interacting statements.

> 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.

This is why I am concerned with parts of the discussion.

First, if intent can be interpreted as having different semantics, we are
not specifying intent properly, and it will likely cause more harm than
good.

Second, if "vague intent" is flooded, then we have magnified the problem.

I continue to think that intent SHOULD go to a parser/compiler first, and
then the output of the parser/compiler (which very well could be some
intermediate form, and not a final form) is then flooded, or put on a
pub-sub bus. Just blindly flooding high-level intent does not seem wise.,

regards,
John

On Tue, Mar 29, 2016 at 9:34 AM, 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.
>
> 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).
>
> Am I over-/mis-interpreting?
>
> Best regards, Laurent.
>
> On 24/03/2016 14:49, EXT Michael Behringer (mbehring) wrote:
>
> 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
>
>
>
>
>
> From: Brian E Carpenter [mailto:[email-masked] <[email-masked]>]
>
> Sent: 24 March 2016 05:53
>
> To: John Strassner <[email-masked]> <[email-masked]>; Duzongpeng
>
> <[email-masked]> <[email-masked]>
>
> Cc: Laurent Ciavaglia <[email-masked]> <[email-masked]>; Jéferson Campos Nobre
>
> <[email-masked]> <[email-masked]>; [email-masked]; Michael Behringer (mbehring)
>
> <[email-masked]> <[email-masked]>; Sheng Jiang <[email-masked]> <[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]> <[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] <[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]>
>
> <[email-masked]> <[email-masked]>] *On Behalf Of *Duzongpeng
>
> *Sent:* 16 March 2016 02:38
>
> *To:* [email-masked]
>
> *Cc:* Laurent Ciavaglia <[email-masked]> <[email-masked]>; Jéferson
>
> Campos Nobre <[email-masked]> <[email-masked]>; Sheng Jiang
>
> <[email-masked]> <[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
>
>
>
> 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/>
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Fri, 1 Apr 2016 19:25:59 -0700

My example of "Arrange VM Guest Distribution so that
CPU utilization is < 70%" is small, but may generate a
large number of target nodes.

regards,
John

On Tue, Mar 29, 2016 at 9:35 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

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

-- 
regards,
John