Subject: [Supa] Revised charter

From: John Strassner <[email-masked]>
Date: Fri, 16 Jan 2015 05:39:23 +0000

This version addresses further comments from Juergen.

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 (OAMA) 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 and multi-technology network abstractions to address the current separation between development and deployment operations. Business agility, along with OpEx reduction, cannot be obtained unless it becomes possible to deploy changes as products.

Policy-based management is one way to help do this, but better abstractions of network resources and services are needed to achieve these goals.

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. Three types of YANG data models are envisioned, each at a different level of abstraction:

  1) model of network at the protocol level

  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 set of Yang models that represent the capabilities of a network within a single administrative domain. This will later be expanded to accommodate multiple administrative domains.

2) A set of Yang models that map network services to the capabilities of a network.

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

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 19 Jan 2015 14:26:07 +0000

Hi,

Here are a few comments and questions, in textual order which is not necessarily the order of their importance.

1.       Unless there is a special reason that I am missing I suggest to avoid creating a new set of acronyms for operations and management applications (OAMA) especially as it's in conflict with the way we define OAM in RFC 6291

2.       I am a little bit concerned that the terminology in the second paragraph is too 'marketing oriented'. Terms like 'multi-level', 'multi-technology', 'business agility', 'deploy change as products' can mean many things to many people.

3.       Do we mean to say that 'better abstraction of network resources and services' is the goal of the WG? 'better' than what?

4.       'needs of the service' means network resources needed for the service to be executed?

5.       Why do we use 'a set of YANG models' and not 'a YANG model' in each of the three work items?

6.       Are the proposed YANG models specific to VPN management or generic?

Thanks and Regards,

Dan

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Friday, January 16, 2015 7:39 AM
To: [email-masked]
Subject: [Supa] Revised charter

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Jan 2015 16:26:47 +0100

Thanks. I like this revision better. Some 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 application…

Like Dan, I suggest to simply remove '(OAMA)' since it is not used anyway.

>   1) model of network at the protocol level

This is a bit vague or open ended. If it is just topology, then say
so. If not, are we going to model everything going on already in the
IETF in terms of modeling efforts? I suppose not. Perhaps you really
meant 'model of the network topology at the protocol level'?
 
>   2) model of the service that relates the needs of the service to the physical and/or virtual topology used by the service

Where is the virtual topology coming from? Is this part of 1)? That
is, does 1) include virtual and non-virtual networks?

> 1) A set of Yang models that represent the capabilities of a network within a single administrative domain. This will later be expanded to accommodate multiple administrative domains.

Can this be more concrete than an open ended set?
 
> 2) A set of Yang models that map network services to the capabilities of a network.
 
Can this be more concrete than an open ended set?
 
> 3) A set of Yang models that specify how policy rules may control the operational, administrative, and management aspects of a network service.

Can this be more concrete than an open ended set?

/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: John Strassner <[email-masked]>
Date: Thu, 22 Jan 2015 02:16:23 +0000

Sorry for the delayed response, please see inline...

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, January 19, 2015 6:26 AM
To: John Strassner; [email-masked]
Subject: RE: Revised charter

Hi,

<js> Agreed! </js>

2.       I am a little bit concerned that the terminology in the second paragraph is too 'marketing oriented'. Terms like 'multi-level', 'multi-technology', 'business agility', 'deploy change as products' can mean many things to many people.
<js>
The following is my understanding of the terms you identified:
   - multi-level:  multiple levels of abstractions
   - multi-technology: an information model is independent of technology,
     whereas a device model is not; what is needed is to first define an
     information model, and then data models that are derived from that one
     information model. Otherwise, you end up with non-interoperable data models.
     Alternatively, we could leave this problem alone and simply build multiple
     data models (e.g., for IP, wireless, and optics), but then how are they orchestrated?
   - business agility: this was for the service providers, but we can remove if that is the consensus
   - deploy change as products: Currently, there is no Customer in DevOps. Someone needs to fix this. I don't see why
     including this important goal as part of the motivation is a bad idea.
</js>

3.       Do we mean to say that 'better abstraction of network resources and services' is the goal of the WG? 'better' than what?
<js> I will think about rewording this.  </js>

<js> Correct </js>

5.       Why do we use 'a set of YANG models' and not 'a YANG model' in each of the three work items?
<js> Because a single YANG model cannot be both generic and define enough detail to be used as an example of VPN management </js>

6.       Are the proposed YANG models specific to VPN management or generic?
<js> I would hope that they are generic. The plan would be to first define generic models, and then derive specific models to support VPN management. So, you would have two sets of YANG modules - one generic, and one for VPN management </js>

Thanks and Regards,

Dan

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923