Subject: [Supa] supa meeting notes and updated charter proposal

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 20 Jan 2015 14:42:15 +0000

Hi,

Please find in the following my summary notes from the supa meeting on Monday 1/19 and an updated charter proposal based on the discussions yesterday.

MEETING NOTES

Discuss charter proposal from John Strassner.

Dan's comments sent prior to the meeting.

Consensus to drop the OAMA acronyms

JF Tremblay: clarification - by multi-level we mean multiple level of abstraction
Dan: use these words

JF: Multi-domain - this is one of the points of differentiation from what ACTN aim to do. Suggests to drop words in charter that mention future support for multiple domains

Dan: what 'better' means?
Tina: policy draft may clarify

Item 4 on Dan's list needs clarification from John Strassner

One model for each of the work items is sufficient - it may be composed of several YANG modules, but this is an implementation detail and decision

VPN management - this comes from Benoit who asked for a more focused charter

Juergen's comments sent prior to the meeting

Juergen: not clear what 'protocol level' means. Needs clarification. Are we doing virtual topology? We do network topology and not device topology. Yet it is not clear what 'topology' means in the context of the charter.
Georgios: we are modeling the network service. For example the VPN service.
I2RS have started some topology modeling work, but they stopped. Should we take over?
Juergen: I2RS have an interim meeting scheduled for Thursday. We can attend and clarify

Do we need explicit text that describes the interaction between SUPA and ACTN? For the type being no need, it should be implicit from the different content of the two charters. Proposing to add topology modeling to capabilities in the first work item.
Juergen: is the topology model generic?
Marc: start discussing with Benoit the responsibilities in doing topology models. Tina and John to talk to Benoit
There is work done by TMForum on MTOSI although it may be more device oriented. We will discuss the TM Forum work in the next call

UPDATED CHARTER PROPOSAL

The rapid increase in the amount and type of traffic, along with the increasing complexity of network architectures, make it significantly more challenging for operations and management applications to manage networks and to deploy new services. Two ways to combat this growing complexity are the use of software abstractions to simplify management, and to increase the Programmatic control over the configuration and operation of these networks. The former enables simplified views of the network to be constructed, which hides complex configuration detail and provides a smaller number of standard control points to configure common functions. The latter uses the abstractions and control points of the former to more quickly define and manage network services. This provides significant benefits in design and deployment agility.

This WG introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g. IP, optical) network abstractions to address the current separation between development and deployment operations.

The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop a model that abstracts network resources and services and a methodology by which the management and monitoring of network services can be done using standardized policy rules. Three types of YANG data models are envisioned, each at a different level of abstraction:

  1) model of network at the protocol level (logical topology)

  2) model of the service that relates the needs of the service to the physical and/or virtual topology used by the service

  3) model of the policy rules for managing the service

Using the above three models, the network is first defined as a topology. A service is then defined as a graph that uses that topology. A set of policy rules is then defined to manage the service. In this approach, the service data models, as well as the policy model, will be derived from a single information model, ensuring that each can be shared and reused as managed objects. Policy rules will be used to define the operational aspects of both the "southbound" (e.g., controller to network device) and "northbound" (e.g., controller to network application) portions of the service environment. The first example that the working group will focus on will be VPN management.

Work items for this WG include:

1) A Yang module that represents the logical topology and capabilities of a network within a single administrative domain. This will later be expanded to accommodate multiple administrative domains.

2) A Yang module that maps network services to the capabilities of a network.

3)  A Yang module that specifies how policy rules may control the operational, administrative, and management aspects of a network service.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 21 Jan 2015 07:04:19 +0000

Hi Dan,

Thank you for the minutes and the new charter. After reading the new charter, I feel it's much more clear and solid than previous ones, like a milestone.

Below part is to Dan as well as the whole group.
After another round of review and discussion, I think there are only some minor issues to be discussed here:

1.      In the first paragraph, "Two ways to combat this growing complexity ...". It seems to me that "two ways " usually means we could choose one and each one is enough for the goal. However, I can feel the following words implicate that these two ways can be combined together. Maybe we could use two aspects or two steps. I'm not a native speaker. Any native speaker have comments on this?

2.      In the second level abstraction "  2) model of the ... to the physical and/or virtual topology ...", while in first work items "A Yang module ... the logical topology ...", three words physical , virtual and logical are used to describe topology. Is it possible for us to make them aligned?

3.      In work items part three "Yang module" are used, while in the whole rest of charter word "model" is used. One module might be not enough to cover one work items, e.g., the topology model may contain several sub modules.   Maybe we should also use model here in work item part?

Regards,
Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 20, 2015 10:42 PM
To: [email-masked]
Subject: [Supa] supa meeting notes and updated charter proposal

Hi,

MEETING NOTES

UPDATED CHARTER PROPOSAL

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 21 Jan 2015 07:42:15 +0000

Thanks for your comments, Will. All you points are good taken - I will wait for more feedback to gather before suggesting more edits.

Regards,

Dan

From: Liushucheng (Will) [mailto:[email-masked]]
Sent: Wednesday, January 21, 2015 9:04 AM
To: Romascanu, Dan (Dan); [email-masked]
Subject: RE: supa meeting notes and updated charter proposal

Hi Dan,

Regards,
Will (Shucheng LIU)

From: Supa [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 20, 2015 10:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Supa] supa meeting notes and updated charter proposal

Hi,

MEETING NOTES

UPDATED CHARTER PROPOSAL

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Jan 2015 08:53:53 +0100

See comments inline...

>   1) model of network at the protocol level (logical topology)

I am still lost here. What is a 'logical' topology. And what does
model of network 'at the protocol level' mean? Network topologies are
layered and I do not understand whether you want to pick out specific
layers or do generic layered network topology. And as said before, it
remains unclear what the scope of 'model of network' is. If it is
'only' topology, then this should say 'topology model' instead of
'model'. And given the text above (multi-technology), I believe the
model must be able to express multiple layers. I think this needs to
be clarified. And I think the words physical/virtual may be important
to include here as well as they are used below (mentioned before
already).

>   2) model of the service that relates the needs of the service to the physical and/or virtual topology used by the service

I thought we agreed to replace 'needs' by something clearer?

>   3) model of the policy rules for managing the service

Here I have a more general clarification question. Back at the end of
last century, there was significant policy work centered around
rule-based policy systems (basically centered around on <event> if
<condition> do <action> rules) while today the focus is on software
controllers that can be seen as magic black boxes to code up and
enforce arbitrary policies. Is SUPA trying to move back to model
policies currently coded into controllers as first class citizens you
want to achieve interoperability on? Is the market ready for moving
back to ideas of the late 1990s? Or am I misunderstanding what is
meant here with 'policy rules'?

> 1) A Yang module that represents the logical topology and capabilities of a network within a single administrative domain. This will later be expanded to accommodate multiple administrative domains.

Replace "A Yang module" with "A data model". As mentioned above, I am
not sure what 'logical topology' really is; anyway, this needs to be
consistent with 1) above.
 
> 2) A Yang module that maps network services to the capabilities of a network.

Replace "A Yang module" with "A data model". I note that the term
'capabilities' only shows up in the in the work items but not in the
above text - perhaps something to improve as well (and to clarify what
'capabilities' are.

> 3)  A Yang module that specifies how policy rules may control the operational, administrative, and management aspects of a network service.

Replace "A Yang module" with "A data model".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 21 Jan 2015 08:23:04 +0000

Hi Juergen,

Thanks for the comments. See in-line. 

Regards,

Dan

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, January 21, 2015 9:54 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [Supa] supa meeting notes and updated charter proposal
> 
> See comments inline...
> 
> > The rapid increase in the amount and type of traffic, along with the
> increasing complexity of network architectures, make it significantly more
> challenging for operations and management applications to manage
> networks and to deploy new services. Two ways to combat this growing
> complexity are the use of software abstractions to simplify management,
> and to increase the Programmatic control over the configuration and
> operation of these networks. The former enables simplified views of the
> network to be constructed, which hides complex configuration detail and
> provides a smaller number of standard control points to configure common
> functions. The latter uses the abstractions and control points of the former to
> more quickly define and manage network services. This provides significant
> benefits in design and deployment agility.
> >
> >
> >
> > This WG introduces the concepts of multi-level (multiple levels of
> abstraction) and multi-technology (e.g. IP, optical) network abstractions to
> address the current separation between development and deployment
> operations.
> >
> >
> >
> > The purpose of the SUPA (Shared Unified Policy Automation) working
> group is to develop a model that abstracts network resources and services
> and a methodology by which the management and monitoring of network
> services can be done using standardized policy rules. Three types of YANG
> data models are envisioned, each at a different level of abstraction:
> >
> >
> >
> I am still lost here. What is a 'logical' topology. And what does model of
> network 'at the protocol level' mean? Network topologies are layered and I
> do not understand whether you want to pick out specific layers or do generic
> layered network topology. And as said before, it remains unclear what the
> scope of 'model of network' is. If it is 'only' topology, then this should say
> 'topology model' instead of 'model'. And given the text above (multi-
> technology), I believe the model must be able to express multiple layers. I
> think this needs to be clarified. And I think the words physical/virtual may be
> important to include here as well as they are used below (mentioned before
> already).
> 

Can you suggest text? 

> >   2) model of the service that relates the needs of the service to the
> > physical and/or virtual topology used by the service
> 

What about

2) model of the service that describes the capabilities and operational parameters required from the physical and/or virtual topology in order to deploy and perform the service

(or suggest better text)

> Here I have a more general clarification question. Back at the end of last
> century, there was significant policy work centered around rule-based policy
> systems (basically centered around on <event> if <condition> do <action>
> rules) while today the focus is on software controllers that can be seen as
> magic black boxes to code up and enforce arbitrary policies. Is SUPA trying to
> move back to model policies currently coded into controllers as first class
> citizens you want to achieve interoperability on? Is the market ready for
> moving back to ideas of the late 1990s? Or am I misunderstanding what is

This needs more discussion in the next call. 

> >
> > Using the above three models, the network is first defined as a topology. A
> service is then defined as a graph that uses that topology. A set of policy
> rules is then defined to manage the service. In this approach, the service
> data models, as well as the policy model, will be derived from a single
> information model, ensuring that each can be shared and reused as managed
> objects. Policy rules will be used to define the operational aspects of both
> the "southbound" (e.g., controller to network device) and "northbound"
> (e.g., controller to network application) portions of the service environment.
> The first example that the working group will focus on will be VPN
> management.
> >
> >
> >
> >
> >
> > 1) A Yang module that represents the logical topology and capabilities of a
> network within a single administrative domain. This will later be expanded to
> accommodate multiple administrative domains.
> >
> 
> not sure what 'logical topology' really is; anyway, this needs to be consistent
> with 1) above.

Why 'data model' rather than 'Yang model'? Do you (we) believe that we may do something else than Yang, or that there is a need to be more 'generic'? 

> 'capabilities' only shows up in the in the work items but not in the above text
> - perhaps something to improve as well (and to clarify what 'capabilities' are.
> 

Same question as above.

> >
> > 3)  A Yang module that specifies how policy rules may control the
> operational, administrative, and management aspects of a network service.
> >
> 

Same question as above.

> Fax:   +49 421 200 3103
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jacobs-
> 2Duniversity.de_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PQSFWW4tOXGOOyJlP9cJVmEgH
> pjM89Fuh99KSxzGFHQ&s=kv2OZynkzQxFKi2baZyV2I1cRdfVQoYr1aMSDpD-
> RBE&e= >
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_supa&d=AwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=PQSFW
> W4tOXGOOyJlP9cJVmEgHpjM89Fuh99KSxzGFHQ&s=2kifYAklsmdWm2_rx6Tf
> dJ-RSq4O0NuU7PeI4k9rwNc&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Jan 2015 10:49:30 +0100

> > important to include here as well as they are used below (mentioned before

The problem is that I do not know what SUPA people plan to work on. To
be consistent with the text you propose for 2), something like this

1) model of the physical and virtual network topology including the
   capabilities (e.g., data rate or latency of links) and operational
   parameters needed to support service deployment over the network
   topology

might be a start. Note that I tried to clarify 'capabilities' as I
understand it, not sure this is everybody's interpretation.

> 2) model of the service that describes the capabilities and operational parameters required from the physical and/or virtual topology in order to deploy and perform the service

Yes, this is an improvement.
 
> Why 'data model' rather than 'Yang model'? Do you (we) believe that we may do something else than Yang, or that there is a need to be more 'generic'?

'YANG data model' is also fine, we should not say 'YANG module'. The
WG should have the freedom to decide how to break the data model into
meaningful modules.

> > - perhaps something to improve as well (and to clarify what 'capabilities' are.

Same answer. ;-)

> > Replace "A Yang module" with "A data model".

Same answer. ;-)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 21 Jan 2015 10:08:07 +0000

See in-line (and more lines deleted)

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Wednesday, January 21, 2015 11:49 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> > > model of network 'at the protocol level' mean? Network topologies
> > > are layered and I do not understand whether you want to pick out
> > > specific layers or do generic layered network topology. And as said
> > > before, it remains unclear what the scope of 'model of network' is.
> > > If it is 'only' topology, then this should say 'topology model'
> > > instead of 'model'. And given the text above (multi- technology), I
> > > believe the model must be able to express multiple layers. I think
> > > this needs to be clarified. And I think the words physical/virtual
> > > may be important to include here as well as they are used below
> (mentioned before already).
> >
> > Can you suggest text?
> >
> 
> The problem is that I do not know what SUPA people plan to work on. To be
> consistent with the text you propose for 2), something like this
> 
> might be a start. Note that I tried to clarify 'capabilities' as I understand it, not
> sure this is everybody's interpretation.

The examples are in synch with my understanding also, I suggest to align the text at 2) as well. 

> 
> > > >   2) model of the service that relates the needs of the service to
> > > > the physical and/or virtual topology used by the service
> > >
> > 2) model of the service that describes the capabilities and
> > operational parameters required from the physical and/or virtual
> > topology in order to deploy and perform the service
> >
> > (or suggest better text)
> 

....

> > > network within a single administrative domain. This will later be
> > > expanded to accommodate multiple administrative domains.
> > > >
> > >
> > > Replace "A Yang module" with "A data model". As mentioned above, I
> > > am not sure what 'logical topology' really is; anyway, this needs to
> > > be consistent with 1) above.
> >
> > Why 'data model' rather than 'Yang model'? Do you (we) believe that we
> may do something else than Yang, or that there is a need to be more
> 'generic'?
> 
> 'YANG data model' is also fine, we should not say 'YANG module'. The WG
> should have the freedom to decide how to break the data model into
> meaningful modules.
> 

Got it - thanks!

---

From: John Strassner <[email-masked]>
Date: Thu, 22 Jan 2015 03:27:55 +0000

Hi Dan, et al.,

Thank you for the updated charter. I have some minor clarifications, as requested in Dan's earlier meeting notes and from the meeting below that I couldn't attend. Additions to the charter are inline, enclosed in <js>..</js>

Note: I am assuming that additional clarification to the charter was requested. If everyone is fine with the charter, I'm fine with deleting my additions, except for the following sentence:

The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop a model that abstracts network resources and services and a methodology by which the management and monitoring of network services can be done using standardized policy rules.

The previous version was:

The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop a methodology by which the management and monitoring of network services can be done using standardized policy rules.

I think that the previous version was better. To me, the phrase "a model that abstracts network resources and services and" indicates that this WG will develop an information model for network resources and services (an information model is independent of platform, language, and protocol, while a data model is not). I think that this goes beyond the purview of the IETF. Furthermore, developing such an information model now puts this WG on a collision course with work being done in several other SDOs.

I think that we should develop an information model fragment (i.e., a part of an information model that cannot stand on its own). If we try and develop an information model, we will rathole on simple things, like what is the superclass of a network service.

Finally, wrt one vs. a "set" of Yang modules, I still vote in favor of a set, as explained in my previous email. In addition to those reasons, note that:

-          A single Yang module will not be capable of representing multiple administrative domains

-          I don't see how a single Yang module can map heterogeneous network services that each have different requirements to a single network, let alone multiple sub-networks

-          I don't see how a single Yang module can represent multiple types of policy rules that could have multiple types of structures (e.g., imperative vs. declarative), scope, and application

UPDATED CHARTER PROPOSAL

The rapid increase in the amount and type of traffic, along with the increasing complexity of network architectures, make it significantly more challenging for operations and management applications to manage networks and to deploy new services. Two ways to combat this growing complexity are the use of software abstractions to simplify management, and to increase the programmatic control over the configuration and operation of these networks. The former enables simplified views of the network to be constructed, which hides complex configuration detail and provides a smaller number of standard control points to configure common functions. The latter uses the abstractions and control points of the former to more quickly define and manage network services. <js> However, combining these two mechanisms provide additional and </js> significant benefits in design and deployment agility.

This WG introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g. IP, optical) network abstractions to address the current separation between development and deployment operations. <js> Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using different components and technologies to implement a network service.</js>

The purpose of the SUPA (Shared Unified Policy Automation) working group is to develop <js> a </js> methodology by which the management and monitoring of network services can be done using standardized policy rules. Three types of YANG data models are envisioned, each at a different level of abstraction:

  2) model of the <js> network </js> service that relates the <js> network resources required by the network service to be correctly executed </js> to the physical and/or virtual topology used by the service

  3) model of the policy rules for managing the <js> network </js> service

Using the above three models, the network is first defined as a <js> logical and/or physical </js> topology. A <js> network service </js> is then defined as a graph that uses that topology. A set of policy rules is then defined to manage the <js> network </js> service. In this approach, the <js> network </js> service data models, as well as the policy model, will be derived from a single information model <js> fragment </js>, ensuring that each can be shared and reused as managed objects. Policy rules will be used to define the operational aspects of both the "southbound" (e.g., controller to network device) and "northbound" (e.g., controller to network application) portions of the service environment. The first example that the working group will focus on will be VPN management.

1) A <js> set of Yang modules <js> that represents <js> a generic form of a logical topology and capabilities </js> of a network within a single administrative domain. This will later be expanded to accommodate multiple administrative domains.

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: Supa [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 20, 2015 6:42 AM
To: [email-masked]
Subject: [Supa] supa meeting notes and updated charter proposal

Hi,

MEETING NOTES

UPDATED CHARTER PROPOSAL

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2015 09:48:42 +0100

> I think that we should develop an information model fragment (i.e., a part of an information model that cannot stand on its own). If we try and develop an information model, we will rathole on simp…

In the IETF, we usually do things more bottom up than top down. And as
such, information models in the IETF are always having a limited
scope. And the motivation to do an information model usually boils
down to the question how likely it will be to have >1 corresponding
data model. If this is unlikely, then we often simply do just a data
model.

To better understand you, do you think that an information model is
most essential or do you think that a generic model that gets refined
for specific networks and services is most essential? (I think one can
do a generic data model with technology specific extensions without
doing an explicit information model.)

> -          A single Yang module will not be capable of representing multiple administrative domains

I do not see this. In principle, you could have a whole world model in
a single YANG module. It does not make much sense from a maintenance
perspective. I fail to see why multiple administrative domains require
multiple YANG modules.

> -          I don't see how a single Yang module can map heterogeneous network services that each have different requirements to a single network, let alone multiple sub-networks

Some as above...

> -          I don't see how a single Yang module can represent multiple types of policy rules that could have multiple types of structures (e.g., imperative vs. declarative), scope, and application

Same as above... 

Anyway, I think Dan and myself already agreed that we should talk
about a YANG data model and leave it to the WG to decide how to best
devide it into a set of YANG modules. Do you agree with that?

> UPDATED CHARTER PROPOSAL

So now we have two charter proposals on the table, how are we going to
merge them?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 22 Jan 2015 08:55:42 +0000

> So now we have two charter proposals on the table, how are we going to

I will try to merge them later today in one text - so that we can comment and improve it. 

Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Jan 2015 09:57:10 +0100

> I will try to merge them later today in one text - so that we can comment and improve it. 

This is very helpful. Thanks a lot.

/js

---

From: John Strassner <[email-masked]>
Date: Thu, 22 Jan 2015 18:52:10 +0000

Inline as well...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, January 22, 2015 12:49 AM
To: John Strassner
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: Re: [Supa] updated charter proposal

<jcs>
Agreed. However, that isn't necessarily the best way to do things. Taken to the extreme, you will end up with a large number of stovepiped models (Yang or otherwise) that redefine the same concept and cannot easily communicate with each other.
</jcs>

<jcs>
It depends on what the end goals of the WG are. IFF you want to ensure interoperability, then I think that an information model is essential. However, if you want to simply demonstrate the feasibility of the idea, then perhaps a generic data model would suffice.
</jcs>

<jcs>
Yang can represent one type of relationship: containment. How do you model constraints between different entities? How do you model semantics associated with a particular endpoint? I'm not arguing against Yang, but I am trying to point out some of its limitations, and am worried that we will end up designing an anti-pattern (i.e., the Big Ball of Mud) if we go down this road. Same for the next two replies...
</jcs>

Some as above...

Same as above... 

<jcs>
I never said no to a Yang data model. I am simply saying that good software engineering separates concerns. Lumping multiple items (i.e., policy, topology, service) into a single model is NOT a good design.
</jcs>

<jcs>
We do not have TWO proposals. We have one with some suggested edits.
</jcs>

/js

_______________________________________________
Supa mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/supa

---

From: John Strassner <[email-masked]>
Date: Fri, 23 Jan 2015 00:11:44 +0000

For brevity and simplicity, this email responds only to the following question from Juergen (prepended with '>', which I believe has still gone unanswered:

> <condition> do <action>
> rules) while today the focus is on software controllers that can be 
> seen as magic black boxes to code up and enforce arbitrary policies. 
> Is SUPA trying to move back to model policies currently coded into 
> controllers as first class citizens you want to achieve 
> interoperability on? Is the market ready for moving back to ideas of 
> the late 1990s? Or am I misunderstanding what is meant here with 'policy rules'?
> 

Dan wrote:

My SHORT reply:
First, I do NOT think that "controllers" have successfully specified what policies are, or how they are modeled. Please show me an example where a policy language, and its corresponding managed objects, are specified in detail for any controller.

Second, I do NOT think that SUPA should choose between different types of policy rules (there are at least 4 that are currently popular).

Third, I think that what is important is that a policy rule should be able to be treated as a managed object. It should be reusable, queryable, and executable. One should be able to compose more powerful policy rules from simpler policy rules. Etc.

My LONGER reply:
Yes, there was significant work focused on event-condition-action (ECA) systems. The good news is that they are still being used. :-)

I believe what Juergen is referring to is the relatively new focus on non-ECA-based systems (e.g., "declarative" or "intent-based" policy).

There have been several reasons for this new focus. One is the belief that "declarative" is somehow "better" (insert your desired metric, such as more efficient, here) than "imperative". Proponents of this belief argue that imperative systems (like ECA) specify the details of the algorithm, whereas declarative systems do not - they simply specify the goal, and leave the magic to the implementation.

However, the true difficulty in implementing policy-based systems is in detecting and resolving conflicts. For example:

   R1:  John gets Gold Service
   R2:  FTP gets Bronze Service

What happens when John sends FTP? (In my case, my laptop explodes, but I digress...)

Clearly, as the declarative system gets broader (and hence more powerful), it also becomes harder to be specific about what you really want to do, and what exceptions you are willing to bear. As another example, if I say:

   R3:  Maximize revenue for today's service offerings

Does that mean that I should mercilessly drop Bronze Service users because Silver and/or Gold users need their resources? And before we flush ECA down the toilet, realize that explicitly specifying the Event, Condition, and Action makes it a lot easier to detect and resolve conflicts.

That being said, the above are **trivial** examples of a policy conflict. Note that the policies that had conflict were **not** in ECA form. This is why I don't agree with the belief that declarative systems are necessarily "better". In fact, I would argue that declarative systems are more prone to conflicts as imperative systems. In fact, in a declarative system, it is likely **not** obvious that two goals conflict; many times, conflicts can only be determined once the goals have been translated to a more specific form, or even an implementation.

In models that I have built, there are four different types of policy rules that are supported:

   1) ECA
   2) goal
   3) utility functions
   4) promises (e.g., autonomous interaction)

I do **not** think that modern policy management systems should have to make a choice between these (or other) approaches. Instead, I think what is important is, for a given type of policy rule, specifying:

  1) how it is defined (its structure, or syntax)
  2) what its dependencies are (its meaning, or semantics)
  3) how it is used

Experience has shown that these aspects are critical in determining whether two policy rules conflict or not.

While it **may** be a good idea for SUPA to pick one form of policy to keep the work focused, there is no fundamental reason why a policy-based management system could not use multiple of these forms. For example, a goal policy might translate to a set of ECA policies. What is important is that SUPA:

  1) treats a policy rule (including metadata) as a set of managed objects
  2) shows how policy rules can be defined, queried, and executed in its framework
  3) shows that modern software engineering principles (e.g., software patterns)
     can be applied to policy, making its implementation robust and scalable.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, January 21, 2015 12:23 AM
To: Juergen Schoenwaelder
Cc: [email-masked]
Subject: Re: [Supa] supa meeting notes and updated charter proposal

Hi Juergen,

Regards,

Dan

Can you suggest text? 

What about

(or suggest better text)

Same question as above.

Same question as above.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jan 2015 09:39:53 +0100

> Agreed. However, that isn't necessarily the best way to do things. Taken to the extreme, you will end up with a large number of stovepiped models (Yang or otherwise) that redefine the same concept…

John, you won't change the IETF into a top-down design approach.

> It depends on what the end goals of the WG are. IFF you want to ensure interoperability, then I think that an information model is essential. However, if you want to simply demonstrate the feasibil…

I won't comment because we will not resolve this.

> Yang can represent one type of relationship: containment. How do you model constraints between different entities? How do you model semantics associated with a particular endpoint? I'm not arguing…

Funny, some people claim YANG can't represent containment and this is
a bug. Perhaps YANG can't represent anything. As long as people are
able to write YANG data models that they implement and interoperate
with, I do not really care. ;-)

I understand that YANG does not provide you the abstractions you love
to work with.

> I never said no to a Yang data model. I am simply saying that good software engineering separates concerns. Lumping multiple items (i.e., policy, topology, service) into a single model is NOT a goo…

And frankly, this was never proposed. Please also pay attention to the
difference between 'model' and 'module'.
 
> We do not have TWO proposals. We have one with some suggested edits.

Whatever you like to call it, conflict resolution is apparently
required.

/js

---

From: John Strassner <[email-masked]>
Date: Mon, 26 Jan 2015 07:20:23 +0000

Juergen,

I don't see how your answers have anything to do with the technical issues raised, so I guess we should just agree to disagree.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, January 23, 2015 12:40 AM
To: John Strassner
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: Re: [Supa] updated charter proposal

 

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jan 2015 10:14:50 +0100

> I don't see how your answers have anything to do with the technical issues raised, so I guess we should just agree to disagree.

Something I can agree with.

/js