Subject: [Anima] Intent yang model - some thoughts

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 18 Mar 2016 09:52:26 +0000

WRT the current discussion on what should be in Intent and what shouldn't, as mentioned before, I think we should leave this to the owner of an autonomic function to decide. This risks "abuse" in a way that wasn't foreseen, but it gives maximum agility, which is what we need to get ANIMA off the ground, IMO. If we are in the nice position to find that it gets adopted a lot, and if there are things that need fixing then, we can work on version 2. 

Several months ago I started with a yang model for Intent, but never finished. Maybe this helps with this discussion. Note I'm not at all a yang expert, so please look more at the general structure for now. Not sure if it helps the discussion... 

+--rw intent
   +--rw meta-data 
   |  +--rw intent-version  uint32   // the version of the intent specification
   |  +--rw timestamp 		uint32   // latest time stamp wins
   |  +--rw administrator 	string   // who created that intent
   |  +--rw device?   		string   // on which node was it created
   |  +--rw execution-time	uint32   // plus other parameters on when to execute
   |  +--rw expiration    	uint32   // when does this intent cease to be valid
   |  +--rw feedback                 // how to let the operator know about success/failure
   |  +--rw signature		??       // intent must be signed
   |
   +--rw scope 
      +--rw domains 
         +--rw domain* [name] 
            +--rw name		string    // is there a fqdn type defined?
            +--rw meta-data           // general about the domain
            |  +--rw include-subdomains	boolean  // should sub-domains follow this policy?
            |  +--rw fail-open  boolean  // fail-open or fail-closed policy
            |  +--rw maintenance-window  // when can critical operations take place
            |  +--rw ...                 // other general policies on domain level
|        ...
            |
            +--rw ani-intent
            +-- (contains all policies which the ANI should follow)
            |  ex: ACP policies, coordination between AN functions, security policies, etc
            |  for ani-intent, scope is always "all" (ie all nodes must process)
            |  ...
...
All of the above MUST be standardised, because it refers to the AN infrastructure itself.
Of the below we need to standardise the structure, but not content for each function
Conceptually, we define Intent for a domain. 
...
            |
            +--rw intent-for-autonomic-functions
               +--rw function_1 [name]
               |  +--rw scope                    // which devices in the domain need to listen. 
               |  |  +--rw all    boolean        // all devices
               |  |  +--rw role   string         // as defined in certificate
               |  |  +--rw dynamic_role  string  // as determined dynamically
               |  |  +--rw tag    string         // can be used for location 
               |  +-- function_intent            // to be defined by function owner
               |
               +--rw function_2 [name]
               |  +--rw scope                    // which devices in the domain need to listen. 
               |  |  +--rw all    boolean        // all devices
               |  |  +--rw role   string         // as defined in certificate
               |  |  +--rw dynamic_role  string  // as determined dynamically
               |  |  +--rw tag    string         // can be used for location 
               |  +-- function_intent            // to be defined by function owner
               |
...
    
If a node receives Intent, it checks: 
1) meta data: Mostly for forwarding and processing of Intent
2) domain info: domain specific policy
3) ANI Intent: Intent for the ANI itself; every node must be able to process that
4) For each of the "function" blocks: 
   - should I run this function? 
   - do I run this function? 
   - if so, forward the rest of that block to the corresponding handler. 
   
I think we want a clean architectural separation between the ANI and the functions. This way every function can do what it wants.

Thoughts? 
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Mar 2016 08:27:35 +1300

Hi Michael,

At a glance, from someone who is a yang beginner, this looks plausible,
although I think we need some analysis of the purpose of many of the
items. Just to pick a random example, consider "maintenance-window".
 - is this fixed or does it change?
 - if it changes, how long in advance does the new intent get sent?
 - what are the semantics (must all ASAs stop operation, etc.)?
 - what happens if maintenance ends early?
 - what happens if maintenance ends late?
In other words these items are not self-defining; each one needs work.

A beginner's question: how is yang serialised on the wire?

And another: can we send partial yang, i.e. only send the bits that changed?

Regards
   Brian

On 18/03/2016 22:52, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Mar 2016 15:50:40 -0400

There are two aspects of this model that have me very confused.

First, in most policy work I have seen one specifies a set of policies, 
and then specifies what they apply to.  This model seems to say "Here 
are a bunch of domains", and then for each domain it lists the policies. 
  Structuring it this way means that reuse is harder.
Somewhat related to that, I find the given metadata confusing:
1) There apparently is some notion that a domain has sub-domains, but 
that there may be things in the higher domain?  And that you may or may 
not want the policy to recurse downwards.  But if you want it to recurse 
downwards, you want it to recurse forever?  (This looks like an 
optimization for sharing policies, but only across all sub-domains of a 
domain.)
2) Fail-open, maintenance-window, and other such items seem to be 
treated as being applicable and relevant to all policies in the domain. 
  That is not at all obvious.
2a) For a given ASA / function, fail-open may be meaningful, and for an 
individual policy the goal may be fail-open or fail-closed.  Or we may 
not even know what "fail" means.
2b) Even for policies where a maintenance window makes sense, it is 
unlikely that all policies will have the same maintenance window. 
Usually, since maintenance can be unpredictable in practice, policies 
have on-off switches individually.

Second, am confused by the modeling for "functions".  I will assume that 
these functions are ASAs.  So they are network-wide targets of policy.
But then I am confused as to what is being modeled here to help the 
function modeling.  I see a boolean for whether the function applies to 
all devices.  It seems unlikely that the choices are all / one, so a 
boolean seems very wrong.  I think the idea is taht you can specify 
"all" or a single role.  I would think a list of roles would actually be 
more useful.
And then I see dynamic-role and tag.  I have no idea what those are 
supposed to mean in an ASA-independent fashion.

I do think that there are some ASA-policy attributes that are useful and 
common.  Things like whether the policy is active.

As a minor confusion, on the scale of things, I presume that 
function_intent is actually the placeholder for the function parameters?

Yours,
Joel

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 21 Mar 2016 10:02:28 +0000

Hi Michael and all,

One quick comment aside from the Intent content discussion: since GRASP uses CBOR, isn't it good for Intent also encoded by CBOR?

YANG model can surely describe an Intent, but it includes lots of features for data manipulating (for Netconf), which might not necessary for Intent describing?. 

Best regards,
Bing

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Behringer (mbehring)
> Sent: Friday, March 18, 2016 5:52 PM
> To: [email-masked]
> Subject: [Anima] Intent yang model - some thoughts
> 
> WRT the current discussion on what should be in Intent and what shouldn't,
> as mentioned before, I think we should leave this to the owner of an
> autonomic function to decide. This risks "abuse" in a way that wasn't
> foreseen, but it gives maximum agility, which is what we need to get ANIMA
> off the ground, IMO. If we are in the nice position to find that it gets
> adopted a lot, and if there are things that need fixing then, we can work on
> version 2.
> 
> Several months ago I started with a yang model for Intent, but never finished.
> Maybe this helps with this discussion. Note I'm not at all a yang expert, so
> please look more at the general structure for now. Not sure if it helps the
> discussion...
> 
> +--rw intent
>    +--rw meta-data
> Of the below we need to standardise the structure, but not content for each
> function Conceptually, we define Intent for a domain.
> ...
>             |
> I think we want a clean architectural separation between the ANI and the
> functions. This way every function can do what it wants.
> 
> Thoughts?
> Michael
>

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 21 Mar 2016 11:44:32 +0100

Hello,

I think that before considering encodings, we should first agree on the 
definition(s) of what we will manipulate.
Let's start with a (formal) definiton of the "ANIMA" intent policy, and 
the hierarchy envisaged and coarse "format".
If we can work out an example with we think capture well enough and 
large enough how and what the "ANIMA" is used for, then I think we will 
already have made great progress.

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: Laurent Ciavaglia <[email-masked]>
Date: Mon, 21 Mar 2016 11:44:38 +0100

Hello,

Let's start with a (formal) definition of the "ANIMA" intent policy, and 

Best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 21 Mar 2016 10:54:27 +0000

Agree; the encoding format question is secondary.
My YANG example was just "playing around", at this point I'm trying to find the right structure. So don't look at the details, just the structure.
Michael

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 21 March 2016 11:45
To: EXT Liubing (Leo) <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; [email-masked]
Subject: Re: [Anima] CBOR for Intent?-//RE: Intent yang model - some thoughts

Hello,

I think that before considering encodings, we should first agree on the definition(s) of what we will manipulate.
Let's start with a (formal) definiton of the "ANIMA" intent policy, and the hierarchy envisaged and coarse "format".
If we can work out an example with we think capture well enough and large enough how and what the "ANIMA" is used for, then I think we will already have made great progress.

Best regards, Laurent.

Hi Michael and all,

Best regards,

Bing

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

Behringer (mbehring)

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

version 2.

discussion...

+--rw intent

   +--rw meta-data

   |  +--rw intent-version  uint32   // the version of the intent

specification

   |  +--rw execution-time       uint32   // plus other parameters on when to

execute

   |  +--rw expiration           uint32   // when does this intent cease to be

valid

   |  +--rw feedback                 // how to let the operator know

about success/failure

   |

   +--rw scope

      +--rw domains

         +--rw domain* [name]

            |  +--rw include-subdomains  boolean  // should

sub-domains follow this policy?

            |  +--rw fail-open  boolean  // fail-open or fail-closed

policy

            |  +--rw maintenance-window  // when can critical

operations take place

            |  +--rw ...                 // other general policies on

domain level

|        ...

            |

            +--rw ani-intent

            |  ex: ACP policies, coordination between AN functions,

security policies, etc

            |  for ani-intent, scope is always "all" (ie all nodes must

process)

            |  ...

...

All of the above MUST be standardised, because it refers to the AN

infrastructure itself.

...

            |

               +--rw function_1 [name]

               |  +--rw scope                    // which devices

in the domain need to listen.

               |  |  +--rw role   string         // as defined in

certificate

               |  |  +--rw dynamic_role  string  // as determined

dynamically

               |  |  +--rw tag    string         // can be used for

location

               |  +-- function_intent            // to be defined by

function owner

               |

               +--rw function_2 [name]

               |  +--rw scope                    // which devices

in the domain need to listen.

               |  |  +--rw role   string         // as defined in

certificate

               |  |  +--rw dynamic_role  string  // as determined

dynamically

               |  |  +--rw tag    string         // can be used for

location

               |  +-- function_intent            // to be defined by

function owner

               |

...

3) ANI Intent: Intent for the ANI itself; every node must be able to process

that

Thoughts?

Michael

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: Mon, 21 Mar 2016 11:00:14 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 20 March 2016 20:28
> To: Michael Behringer (mbehring) <[email-masked]>; [email-masked]
> Subject: Re: [Anima] Intent yang model - some thoughts
> 
> Hi Michael,
> 
> although I think we need some analysis of the purpose of many of the items.
> Just to pick a random example, consider "maintenance-window".

Consider my proposal more of a brainstorming session than a ready-to-use model. I'm focusing just on the structure, and the fields are examples of what could be there. 
 
> And another: can we send partial yang, i.e. only send the bits that changed?

Not a YANG expert either, and as mentioned by Laurent, the encoding is a secondary question. 

Michael

> > WRT the current discussion on what should be in Intent and what
> shouldn't, as mentioned before, I think we should leave this to the owner of
> an autonomic function to decide. This risks "abuse" in a way that wasn't
> off the ground, IMO. If we are in the nice position to find that it gets adopted
> a lot, and if there are things that need fixing then, we can work on version 2.
> >
> > Several months ago I started with a yang model for Intent, but never
> finished. Maybe this helps with this discussion. Note I'm not at all a yang
> expert, so please look more at the general structure for now. Not sure if it
> helps the discussion...
> >
> > +--rw intent
> >    +--rw meta-data
> > Of the below we need to standardise the structure, but not content for
> > each function Conceptually, we define Intent for a domain.
> > ...
> >             |

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 21 Mar 2016 12:53:18 +0100

Michael, all,

Thanks for providing your example!

My first comment would be to consider "breaking" the model into parts.
Some clarifications:
     -I don't think the ANIMA intent should be one single (big) file. 
This will be cumbersome to manage/update, and contrary to the PBM 
approach principles.
     -Thus, an ANIMA network will have several, concurrent intents.

Therefore, I think we should define:
     -A format of the ANIMA intent that applies to the different target 
entities / roles.
     -e.g. the ANI, the ASAs.

Can/should the ANI intent and ASA intent use the same base model?
     -> I think this will depend if they share enough in common.

I will try to provide more details in the future (now busy with latest 
ID updates).

Thanks, best regards, Laurent.

On 21/03/2016 11:54, EXT Michael Behringer (mbehring) wrote:
> My YANG example was just “playing around”, at this point I’m trying to 
> find the right structure. So don’t look at the details, just the 
> structure.
>
> Michael
>
> *From:*Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* 21 March 2016 11:45
> *To:* EXT Liubing (Leo) <[email-masked]>; Michael Behringer 
> (mbehring) <[email-masked]>; [email-masked]
> *Subject:* Re: [Anima] CBOR for Intent?-//RE: Intent yang model - some 
> thoughts
>
> Hello,
>
> I think that before considering encodings, we should first agree on 
> the definition(s) of what we will manipulate.
> Let's start with a (formal) definiton of the "ANIMA" intent policy, 
> and the hierarchy envisaged and coarse "format".
> large enough how and what the "ANIMA" is used for, then I think we 
> will already have made great progress.
>
> Best regards, Laurent.
>
>     One quick comment aside from the Intent content discussion: since
>     GRASP uses CBOR, isn't it good for Intent also encoded by CBOR?
>
>     YANG model can surely describe an Intent, but it includes lots of
>     features for data manipulating (for Netconf), which might not
>     necessary for Intent describing?.
>
>     Best regards,
>
>     Bing
>
>         To: [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: "Liubing (Leo)" <[email-masked]>
Date: Mon, 21 Mar 2016 11:53:24 +0000

Hi Michael, Laurent, and all
Yes, encoding is a secondary issue. Just had a random comment:)

Best regards,
Bing

From: Michael Behringer (mbehring) [mailto:[email-masked]]
Sent: Monday, March 21, 2016 6:54 PM
To: Laurent Ciavaglia; Liubing (Leo); [email-masked]
Subject: RE: [Anima] CBOR for Intent?-//RE: Intent yang model - some thoughts

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 21 March 2016 11:45
To: EXT Liubing (Leo) <[email-masked]<mailto:[email-masked]>>; Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] CBOR for Intent?-//RE: Intent yang model - some thoughts

Hello,

Best regards, Laurent.

Hi Michael and all,

Best regards,

Bing

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

Behringer (mbehring)

version 2.

discussion...

+--rw intent

   +--rw meta-data

specification

execute

valid

about success/failure

   |

   +--rw scope

      +--rw domains

         +--rw domain* [name]

policy

operations take place

domain level

|        ...

            |

            +--rw ani-intent

security policies, etc

process)

            |  ...

...

infrastructure itself.

...

            |

               +--rw function_1 [name]

certificate

dynamically

location

function owner

               |

               +--rw function_2 [name]

certificate

dynamically

location

function owner

               |

...

that

Thoughts?

Michael

Anima mailing list

Anima mailing list

--
Laurent Ciavaglia
Senior Research Manager
Bell Labs, Nokia

+33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 08:28:11 +1300

> I think that before considering encodings, we should first agree on the definition(s) of what we will manipulate.

That is good systems engineering, but I do want to understand the implications
on the wire as well. For example, WSDL was very popular for a while but is a
horribly inefficient wire format. So if we are going to design in yang, I want
to be sure that it will look reasonable on the wire.

[Bing - from my prototype, I've learned that pretty much anything can be encoded
in CBOR if you want. If you can represent a data structure as an object, the
CBOR 'dumps' and 'loads' functions convert to and from CBOR bytes. That works
in all the likely programming languages.]

> My first comment would be to consider "breaking" the model into parts.

I fully agree. This will also make the mechanics of flooding easier and
also make incremental updates possible.

    Brian

> Some clarifications:
>     -I don't think the ANIMA intent should be one single (big) file. This will be cumbersome to manage/update, and contrary to
> the PBM approach principles.
>     -A format of the ANIMA intent that applies to the different target entities / roles.
>     -e.g. the ANI, the ASAs.
> 
> I will try to provide more details in the future (now busy with latest ID updates).
> 
>> My YANG example was just “playing around”, at this point I’m trying to find the right structure. So don’t look at the details,
>> just the structure.
>>
>> Michael
>>
>> *To:* EXT Liubing (Leo) <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; [email-masked]
>> *Subject:* Re: [Anima] CBOR for Intent?-//RE: Intent yang model - some thoughts
>>
>> Hello,
>>
>> If we can work out an example with we think capture well enough and large enough how and what the "ANIMA" is used for, then I
>> think we will already have made great progress.
>>
>> Best regards, Laurent.
>>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Mar 2016 04:08:34 +0000

Hi Brian,

> Sent: Tuesday, March 22, 2016 3:28 AM
> To: Laurent Ciavaglia; Michael Behringer; Liubing (Leo); [email-masked]
> That is good systems engineering, but I do want to understand the
> implications on the wire as well. For example, WSDL was very popular for a
> while but is a horribly inefficient wire format. So if we are going to design in
> yang, I want to be sure that it will look reasonable on the wire.
[Bing] YANG is not on the wire, it is the model mostly for NMS or device-management-module developers. The on-wire form is XML-like structure (encapsulated in Netconf) constructed according to the YANG model.
(Actually YANG was designed specifically for manipulating config/state data through Netconf.)
So, for us, we can make either XML or YANG on wire. But YANG sentences on wire seems not a decent way for me.
XML is ok, but I don't know which is better, comparing to CBOR.

Best regards,
Bing 

> [Bing - from my prototype, I've learned that pretty much anything can be
> encoded in CBOR if you want. If you can represent a data structure as an
> object, the CBOR 'dumps' and 'loads' functions convert to and from CBOR
> bytes. That works in all the likely programming languages.]
> 
> I fully agree. This will also make the mechanics of flooding easier and also
> make incremental updates possible.
> 
>     Brian
> 
> > Some clarifications:
> >> My YANG example was just “playing around”, at this point I’m trying
> >> to find the right structure. So don’t look at the details, just the structure.
> >>
> >> Michael
> >>
> >>            |  +--rw timestamp            uint32   // latest time
> stamp
> >>         wins
> >>
> >>            |  +--rw administrator        string   // who created
> that
> >>         intent
> >>
> >>            |  +--rw device?              string   // on which
> node was
> >>         it created
> >>
> >>            |  +--rw expiration           uint32   // when does
> this
> >>         intent cease to be
> >>
> >>         valid
> >>
> >>                     +--rw name           string    // is there a
> fqdn
> >>         type defined?
> >>
> >>                     |  +--rw ...                 // other
> general
> >>         policies on
> >>                        |  |  +--rw tag    string         // can
> be
> >>         used for
> >>
> >>         location
> >>
> >>                        |  +-- function_intent            // to
> be
> >>         defined by
> >>
> >>         function owner
> >>
> >>                        |
> >>
> >>                        +--rw function_2 [name]
> >>
> >>                        |  +--rw scope                    //
> which devices
> >>
> >>                        |  |  +--rw tag    string         // can
> be
> >>         used for
> >>
> >>         location
> >>
> >>                        |  +-- function_intent            // to
> be
> >>         defined by
> >>
> >>         function owner
> >>
> >>                        |
> >>
> >>         ...
> >>
> >> LinkedIn: laurentciavaglia
> >> <http://fr.linkedin.com/in/laurentciavaglia/>
> >>
> >
> >
> >

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Mar 2016 07:44:31 +0100

YANG is a data modeling language for data at rest (e.g., in a management
data repository); it is not designed for describing protocol data units
(we recently have been using CDDL for the latter).

https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-08

YANG data from (or going into) a repository can be represented on the
wire in XML (native RFC 6020), JSON, and now also in CBOR:

https://tools.ietf.org/html/draft-ietf-netmod-yang-json-09
https://tools.ietf.org/html/draft-veillette-core-yang-cbor-mapping-00

Indeed, the COMI project in the CoRE working group is about enabling
RESTCONF style transactions on YANG-modeled data within constrained
devices, employing CBOR representation as one of the crucial
optimizations to make this possible.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2016 08:01:49 +1300

Thanks Carsten. draft-veillette-core-yang-cbor-mapping looks like
the correct solution in the GRASP context, if someone provides the
appropriate run-time support code.

IMHO using the XML or JSON formats would be a mistake.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 23 Mar 2016 03:46:32 +0000

Hi all,

According to Carsten's education (thanks a lot!), and recent discussion, I realize we need to separate two things for Intent:
1. Encoding. Seems CBOR is a decent choice as discussed recently.
2. Modeling/describing Language. 

I think No.2 is not only a language choice problem (CDDL vs YANG or other), the essential thing is how we expect the Intent to be managed.
In my mind, there are two ways:
a)  Just like flooding TLVs (Intent Distribution). Each node just stored the received Intent, maybe there needs to be some simple update operation according to the Intent content, but there's no restful operation through protocol between nodes. In this case, Intent is just on-wire protocol data, the same as a GRASP message or option. (Then CDDL is the proper choice as Carsten commented. Carsten: please correct me if I got your point wrong).
b)  Sophisticated operation on Intent, e.g. partial update, deleting, query etc. Then we probably need restful operation through protocol to manipulate Intent repository stored in nodes. In this case, Intent is a model for data construction and manipulating, it's not on-wire. (Just like Netconf/Restconf+YANG style.)

Apparently, GRASP does not provide any restful operation capability so far. If we want to manage Intent in this way, we either extend GRASP or even introduce another protocol.
However, since Intent is mostly high-level policy-like content, I personally tend to simply distribute the Intent as choice a). Choice b) seems over complex for me.

Thoughts?

Best regards,
Bing

> Sent: Wednesday, March 23, 2016 3:02 AM
> To: Carsten Bormann; Liubing (Leo)
> Cc: Laurent Ciavaglia; Michael Behringer; [email-masked]
> Thanks Carsten. draft-veillette-core-yang-cbor-mapping looks like the
> correct solution in the GRASP context, if someone provides the appropriate
> run-time support code.
> 
> > YANG is a data modeling language for data at rest (e.g., in a
> > management data repository); it is not designed for describing
> > protocol data units (we recently have been using CDDL for the latter).
> >

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 23 Mar 2016 09:55:18 +0100

Hi Bong, All,

Please see below for my comments.

> 2. Modeling/describing Language.
I would say that we need more (depending on the final definition for 
ANIMA intent).
If ANIMA intent is/becomes an element of a Policy Based Management 
approach, then there are several elements to consider, i.e. the 
classical PBM machinery.

> b)  Sophisticated operation on Intent, e.g. partial update, deleting, query etc. Then we probably need restful operation through protocol to manipulate Intent repository stored in nodes. In this ca…
I think both aspects are not excluding each other.
ANIMA intent will need to be "written", translated in various 
formats/encodings, and distributed.
If we refer to the policy continuum (which we need to define for ANIMA 
environments), a) and b) will both be specified.
I don't see how we can manage an ANIMA networks in a comprehensive way 
without considering more than just how the intent could be distributed 
(but this needs to be considered / part of the solution).

One element that might be interesting to consider is if/how the specific 
characteristics of autonomic networks/functions create a special case 
for PBM/intent based networking, e.g. by providing advanced-embedded 
reasoning/processing capabilities. So far we have not explore this 
aspect in the ANIMA WG (to my knowledge). There is a rich literature on 
PBM + autonomics.

As for RESTful "operations", this is a possible approach but we should 
probably first discuss the requirements before choosing a type of 
communication scheme (cf characteristics of autonomic networks).

> However, since Intent is mostly high-level policy-like content, I personally tend to simply distribute the Intent as choice a). Choice b) seems over complex for me.
I think it is not as simple as 'just" choosing a).
We need a system/functions/mechanisms to allow creating the intent 
(content), process it at the different levels, check for 
conflict/consistency, etc.

Best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 23 Mar 2016 11:19:55 +0000

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 20 March 2016 20:51
> To: Brian E Carpenter <[email-masked]>; Michael Behringer
> First, in most policy work I have seen one specifies a set of policies, and then
> specifies what they apply to.  This model seems to say "Here are a bunch of
> domains", and then for each domain it lists the policies.

That is a good discussion to have. I don't have a good answer at the moment. 

> 1) There apparently is some notion that a domain has sub-domains, but that
> there may be things in the higher domain?  And that you may or may not
> want the policy to recurse downwards.  But if you want it to recurse
> downwards, you want it to recurse forever?  (This looks like an optimization
> for sharing policies, but only across all sub-domains of a
> domain.)

We need to find the right way to do this. But some form of "inheritance" of intent from parent to child domain seem a good idea. There are various ways to do that, we could turn the definition around and just list the (sub-)domains, as you suggested; we could recurse indefinitely until another domain definition explicitly stops it, we could limit the number of recursions, to be seen. 

> 2) Fail-open, maintenance-window, and other such items seem to be treated
> as being applicable and relevant to all policies in the domain.

And it may not be in the right spot; again, this is really a brainstorming exercise; the main point is that there exist parameters (not a good word; intent-bits?)  on each of those levels: One for the intent file itself, one per domain, etc. 

> individual policy the goal may be fail-open or fail-closed.  Or we may not even
> know what "fail" means.

Here, I'm referring to the AN infrastructure. There will be cases where security checks fail, but communication is still possible; for those, we need to allow Intent "fail-open" or "fail-close". 

> 2b) Even for policies where a maintenance window makes sense, it is unlikely
> that all policies will have the same maintenance window.
> Usually, since maintenance can be unpredictable in practice, policies have on-
> off switches individually.

The proposed structure is not cast in stone, needs discussion ;-)

> function modeling.  I see a boolean for whether the function applies to all
> devices.  It seems unlikely that the choices are all / one, so a boolean seems
> very wrong.  I think the idea is taht you can specify "all" or a single role. 

indeed.

> I
> would think a list of roles would actually be more useful.

Sorry, not explained yet, and the details are for future discussion. 
 
> As a minor confusion, on the scale of things, I presume that function_intent
> is actually the placeholder for the function parameters?

yes. 

Sorry for causing all the confusion, again, let's focus on the overall structure so far, not on the detailed parameters. The parameters shown are examples only. 

Michael
 
> > At a glance, from someone who is a yang beginner, this looks
> > plausible, although I think we need some analysis of the purpose of
> > many of the items. Just to pick a random example, consider "maintenance-
> window".
> >> Of the below we need to standardise the structure, but not content
> >> for each function Conceptually, we define Intent for a domain.
> >> ...
> >>              |

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2016 08:27:34 +1300

On 23/03/2016 21:55, Laurent Ciavaglia wrote:
...
>> b)  Sophisticated operation on Intent, e.g. partial update, deleting, query etc.

I'm pretty sure we will need partial update and deletion. I don't expect we
will need query.

...
> As for RESTful "operations", this is a possible approach but we should probably first discuss the requirements before choosing a type of communication scheme (cf characteristics of autonomic networks).

I agree. RESTful has become a sort of religion recently but it's really just a
way of almost obtaining transactional integrity across proxies and caches.
It may not be what we need (for example, we might need semantics more like DNCP).
It may be that simple flooding (already supported by GRASP) will be sufficient,
if the update and deletion operations are atomic.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Mar 2016 13:43:35 +1300

On 24/03/2016 08:48, Jéferson Campos Nobre wrote:
> Em qua, 23 de mar de 2016 às 16:27, Brian E Carpenter <
> [email-masked]> escreveu:
> 
> Probably, query would be needed for (self?) monitoring and intent
> verification and consistency checks.

Actually the query in that case could just be a Request Synch for
the relevant subset of intent. The objective "Intent.PrefixManager" is the
example used in draft-ietf-anima-prefix-management.

    Brian
> + 1

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 24 Mar 2016 07:59:27 +0000

Let me challenge that: Why do we need partial updates? I claim full update should do. let's keep it as simple as possible. 

I think this statement is true if: 
- updates are infrequent (most importantly)
- Intent doesn't become huge. 

If we really mean what we say ("high level guidance"), then it will change once a month at most. Perfectly ok to flood even a few MBy with that frequency. 

If not, which assumption is wrong and why? 

Michael

> Sent: 24 March 2016 01:44
> To: Jéferson Campos Nobre <[email-masked]>; Laurent Ciavaglia
> <[email-masked]>; Liubing (Leo) <[email-masked]>;
> Carsten Bormann <[email-masked]>
> Cc: Michael Behringer (mbehring) <[email-masked]>; [email-masked]
> Subject: Re: [Anima] How we manage Intent?-//RE: CBOR for Intent?-//RE:
> Intent yang model - some thoughts
> 
> >>>> b)  Sophisticated operation on Intent, e.g. partial update,
> >>>> deleting,
> >> query etc.
> >>
> >> I'm pretty sure we will need partial update and deletion. I don't
> >> expect we will need query.
> >>
> >
> Actually the query in that case could just be a Request Synch for the relevant
> subset of intent. The objective "Intent.PrefixManager" is the example used
> in draft-ietf-anima-prefix-management.
> 
>     Brian
> >
> >
> >>
> >> ...
> >> I agree. RESTful has become a sort of religion recently but it's
> >> really just a way of almost obtaining transactional integrity across
> >> proxies and caches.
> >> It may not be what we need (for example, we might need semantics
> more
> >> like DNCP).
> >> It may be that simple flooding (already supported by GRASP) will be
> >> sufficient, if the update and deletion operations are atomic.
> >>
> >>
> > + 1
> >
> >
> >>    Brian
> >>

---

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

There could be a 3rd case for partial updates: there are multiple sources for
intent in the network.

I don't really have a feeling for frequency, but I do agree that it should
be relatively rare.

"Huge" is another discussion. If it does get to MB we might as well distribute
it with FTP :-). I was hoping for kB.

    Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 23 Mar 2016 19:48:37 +0000

> sufficient,
+ 1

---

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

> Sent: 24 March 2016 20:30
> To: Michael Behringer (mbehring) <[email-masked]>; Jéferson Campos
> Nobre <[email-masked]>; Laurent Ciavaglia
> Cc: [email-masked]

In my thinking: Latest version wins; never mind where it came in. Yes, this is a big point, and we better check that this isn't too simplistic; but I don't see why this would NOT be sufficient, and it would then result in a really simple algorithm (see separate mail). 
 
> I don't really have a feeling for frequency, but I do agree that it should be
> relatively rare.
> 

I don't think there's anything wrong with FTP :-)  (or TFTP, since we leverage the security of the ACP). 

Michael