Subject: Re: [Supa] supa charter revision 2015-01-29

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 15:47:22 +0000

Dear all,

Here is a revision based on yesterday's charter version, and incorporating Dan's proposed text, trying to introduce the focus required by Benoit. More inputs are very welcome.

supa charter revision 2015-02-03
-------
Rapid growth in the amounts and types of traffic flowing over increasingly complex network architectures makes it significantly more challenging for operations and management applications to manage networks and to deploy new services than in previous times. 

Two complementary mechanisms for dealing with this growing complexity are 
(1) the use of software abstractions to simplify management and 
(2) the increase in programmatic control over the configuration and operation of such networks. 

The first mechanism 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 second mechanism uses the abstractions and control points to more quickly define and manage network services. Moreover, combining these two mechanisms provides additional and significant benefits in design and deployment agility.  

The purpose of the SUPA (Simplified Use of Policy Abstractions) working group is to develop a methodology by which management of network services can be done using standardized policy rules.

Three types of YANG data models are envisioned: 
1) model of the physical and virtual network topology including the resources (e.g., data rate or latency of links) and operational parameters needed to support service deployment over the network topology 
2) model of the network service (e.g., VPNs) and the network resources required by the network service to be correctly deployed and executed on the physical and/or virtual topology
3) model of policy rules for managing the network service and mapping services dynamically to the network topology and network resources 

Using the above three models, the network is first defined as a topology. A service is then defined as a service topology layered above the network topology. A set of policy rules is then defined to manage the service. In this approach, service specific policy data models will be derived from a generic policy model, ensuring that policies have a common structure and can be easily reused as managed objects.

The working group will focus in the first phase on VPN inter-datacenter traffic management in the case of a Distributed Data Center (DDC), including the automated provisioning of site-to-site virtual private networks (VPNs) of various types (for example IPsec, tunnels, MPLS L2 and L3).

Work items for this phase include:

1) A Yang data model that represents a generic form of the physical
   and virtual topology and the resources of a network within a single
   administrative domain.

2) A Yang data model that describes network services, their resource
   requirements as well as service specific parameters.

3) A Yang data model that specifies policy rules controlling a network
   service. These policy rules are generic and cover operational and
   management aspects of the service and map the service to a network
   topology. The rules ideally are generic can be applied to any type
   of service model.

The working group will communicate with other SDOs (MEF, ETSI) working
on related issues.
------

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Thursday, January 29, 2015 11:33 PM
To: [email-masked]
Subject: Re: [Supa] supa charter revision 2015-01-29

> On Jan 29, 2015, at 10:17 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
>> The service modeling part could be defined further maybe. Especially a sentence like "A service is then defined as a graph that uses that topology.” could be improved, but I can live with this sentence as it is now. 
> 
> Yes, I agree with your comment to eliminate the work 'graph'. I kind 
> of lost that edit. What about this replacement:
> 
>  A service is then defined as a service topology layered above the  
> network topology.

Good for me. Vague enough for thought-provoking discussions, hopefully. 

/JF

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 17:58:36 +0100

> Here is a revision based on yesterday's charter version, and incorporating Dan's proposed text, trying to introduce the focus required by Benoit. More inputs are very welcome.

I have reworked the text such that it is possible to diff it against
previous versions. I am attaching the edited text and the diff. I
notice that the paragraph discussion multi-levels of abstractions and
multi-technology got removed from the charter. Any specific reason for
this?

/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/>
--- supa-charter-2015-01-31.txt	2015-01-31 11:02:10.000000000 +0100
+++ supa-charter-2015-02-03.txt	2015-02-03 17:55:24.000000000 +0100
@@ -1,4 +1,4 @@
-SUPA CHARTER PROPOSAL (2015-01-29 15:20 GMT)
+SUPA CHARTER PROPOSAL (2015-02-03)
 
 Rapid growth in the amounts and types of traffic flowing over
 increasingly complex network architectures makes it significantly more
@@ -15,19 +15,10 @@
 network services. Moreover, combining these two mechanisms provides
 additional and significant benefits in design and deployment agility.
 
-This working group introduces the concepts of multi-level (multiple
-levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS)
-network abstractions to address the current separation between
-development and deployment operations. Multiple levels of abstraction
-enable common concepts present in different technologies and
-implementations to be represented in a common manner. This facilitates
-using diverse components and technologies to implement a network
-service.
-
-The purpose of the SUPA (Shared Unified Policy Automation) working
-group is to develop a methodology by which management of network
-services can be done using standardized policy rules. Three types of
-YANG data models are envisioned:
+The purpose of the SUPA (Simplified Use of Policy Abstractions)
+working group is to develop a methodology by which management of
+network services can be done using standardized policy rules. Three
+types of YANG data models are envisioned:
 
 1) model of the physical and virtual network topology including the
    resources (e.g., data rate or latency of links) and operational
@@ -49,15 +40,13 @@
 policies have a common structure and can be easily reused as managed
 objects.
 
-The first use case that the working group will focus on will be VPN
-inter-datacenter traffic management, including the automated
-provisioning of site-to-site virtual private networks (VPNs) of
-various types (for example IPsec, tunnels, MPLS L2 and L3).
+The working group will focus in the first phase on VPN
+inter-datacenter traffic management in the use case of a Distributed
+Data Center, including the automated provisioning of site-to-site
+virtual private networks (VPNs) of various types (for example IPsec,
+tunnels, MPLS L2 and L3).
 
-The working group will communicate with other SDOs (MEF, ETSI) working
-on related issues.
-
-Work items for this working group include:
+Work items for this phase include:
 
@@ -71,3 +60,7 @@
+
+The working group will communicate with other SDOs (MEF, ETSI) working
+on related issues.
+

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 17:03:13 +0000

Dear Juergen,

Oops, my bad,

When I copied and pasted from yesterday's slides, forgot page 11 "Charter 2/4". That's why it looked shorter to me;-)

Put them back:
------
This working group introduces the concepts of multi-level (multiple levels of abstraction) and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to address the current separation between development and deployment operations. 

Multiple levels of abstraction enable common concepts present in different technologies and implementations to be represented in a common manner. This facilitates using diverse components and technologies to implement a network service.
------

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 12:59 AM
To: Tina TSOU
Cc: JF Tremblay; [email-masked]
Subject: Re: [Supa] supa charter revision 2015-01-29

> Here is a revision based on yesterday's charter version, and incorporating Dan's proposed text, trying to introduce the focus required by Benoit. More inputs are very welcome.

I have reworked the text such that it is possible to diff it against previous versions. I am attaching the edited text and the diff. I notice that the paragraph discussion multi-levels of abstractions and multi-technology got removed from the charter. Any specific reason for this?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 18:11:16 +0100

> When I copied and pasted from yesterday's slides, forgot page 11 "Charter 2/4". That's why it looked shorter to me;-)

So here is the bug fixed version of today and an updated diff.

/js

+++ supa-charter-2015-02-03.txt	2015-02-03 18:09:56.000000000 +0100
 
 Rapid growth in the amounts and types of traffic flowing over
 increasingly complex network architectures makes it significantly more
@@ -24,10 +24,10 @@
 using diverse components and technologies to implement a network
 service.

@@ -49,15 +49,13 @@

 
@@ -71,3 +69,7 @@

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 17:27:57 +0000

Dear Juergen et al,

Use cases reflected in the list of work items?

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 1:11 AM
To: Tina TSOU
Cc: JF Tremblay; [email-masked]
Subject: Re: [Supa] supa charter revision 2015-01-29

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Feb 2015 18:30:31 +0100

> Use cases reflected in the list of work items?

I did not do edits, I just spend time to get things back under
control if that is what you mean?

/js

---

From: Tina TSOU <[email-masked]>
Date: Tue, 3 Feb 2015 17:32:07 +0000

Dear Juergen,

Yup.

It needs to be edited.

Thank you,
Tina

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2015 1:31 AM
To: Tina TSOU
Cc: JF Tremblay; [email-masked]
Subject: Re: [Supa] supa charter revision 2015-01-29

> Use cases reflected in the list of work items?

I did not do edits, I just spend time to get things back under control if that is what you mean?

/js