Subject: [Supa] Area hand-off, and some friendly advice ...

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 Sep 2014 11:41:52 -0500

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA 
really belongs in OPS. I've requested that the area affiliation in 
http://www.ietf.org/list/nonwg.html be updated to reflect that.

Benoit will be your AD for additional charter discussion.

If I might offer some friendly advice, several ADs are fairly confused 
about the relationship between openv6, APONF, and SUPA. If you could put 
together a short paragraph that's something like "we started openv6 to 
do X, then we realized we needed to do Y so we proposed APONF, and after 
discussions in Toronto, we chose a different direction with SUPA because 
of Z", that would be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the 
description at https://www.ietf.org/mailman/listinfo/supa more 
understandable for people who haven't been following the work - if you 
intend to charter a working group, you'll want people to understand what 
you're proposing.

You should probably keep in mind that people who talk over a long period 
of time are likely to develop a shared understanding that people who 
weren't involved don't understand clearly. If there's a smart newcomer 
who could look over problem statements, proposed charters and see what's 
not clear to newcomers, that would likely be helpful as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, where 
all ADs lurk sooner or later ...

Spencer

---

From: Tina TSOU <[email-masked]>
Date: Mon, 15 Sep 2014 20:57:32 +0000

Dear Spencer, Benoit et al,

Thank you for your friendly advice. 

Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic perspective, based on the list discussion. Look forward to more opinions and discussions on the list.

* SUPA draft charter:
--------------

SUPA (Shared Unified Policy Automation)

Target Area: OPS

Description of Working Group:

Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more services depend on them. Programmatic ways to configure networks, often  called software-defined, are considered by many network operators in order to shift the balance in their favor.
 
Automation of configuration may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through abstraction provided by such systems to applications running above them (on the so-called northbound side). Well-designed abstractions are able to provide a wide range of granularity for various applications needs, from the lower-level physical network to high-level application services.
 
Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications to communicate with network controllers of all types.
 
The interface definitions will be based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of abstraction and granularity. Such a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology for standard northbound configuration.
 
Work items for SUPA include:
 
1) Choice of a modeling language used by the group to describe the network graph. Existing modeling languages such as YANG will be considered for this purpose unless no suitable one is found.
 
2) Choice of a transport protocol for the modeling language mentioned above. The group will re-use a protocol already defined as a transport for the modeling language, such as NETCONF or RESTCONF in the case of YANG.
 
3) The definition of a standardized model for a network topology graph. This model may be used to describe topologies at any functional layer, from physical networks to network services and higher abstractions. The nodes of this graph may describe physical nodes as well as virtualized ones.
 
4) The definition and standardization of a number of basic abstracted models using network graphs. These might include, but are not limited to, L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.  
 
5) Guidelines for the mapping of abstract model information to physical or virtualized network components.  

Proposed milestones for the working group:
 
-   Produce a problem statement document for SUPA.

-   Produce a gap analysis for SUPA in order to verify overlap with the work of other IETF groups.

-   Produce a requirement document describing the desired properties of an abstract multi-layer network graph definition.

-   Produce a gap analysis of existing modeling language, their characteristics, possible transport protocols and how they compare to the SUPA requirements.

-   Produce a document specifying the model for a generic multi-layer network graph.

-   Produce several documents describing different levels of abstract views using the network graph model defined above, including physical view, logical view, layer-3 view, configuration view, performance probing view, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering.  

------------

* OPENv6, APONF and SUPA group historic perspective
-------------------------------------------------------------------------

Most IETF working groups are formed in the interest of solving some actual real-world problem from network operators, developers or manufacturers and the initial work from the OPENv6 group was no exception. Some operators saw a common interest in defining a common approach for the deployment of IPv6 transition tools. Although the preferred way of deploying IPv6 remains by dual-stacking, several operators have deployed additional transition tools such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent of speeding up or to provide more flexibility in their IPv6 services. Each of these protocols presents its own set of deployment challenges and failure modes for users, either because of unsupported applications, partial implementations in some off-the-shelf devices such as home routers or some limitations of the protocols themselves to name a few cases. 

The fact these protocols are often deployed with techniques targeting the extension of IPv4 service, such as Carrier Grade NAT, making their deployment even more complex, especially when targeting minimal end-user impact. Although some approaches in solving this were proposed, for example in RFC6264, the market hasn't seen the advent of configurable CGN devices or adaptive home gateways. The only solution for operators is to have an agile way to provision rapidly and easily any type of IPv6 or IPv4 service depending of the specific needs of each end-user and their device. These changes must be performed with respect to the operator existing policies regarding the network, billing, security and other constraints. 

While exploring these issues, it became clear the best way to address them would be to use a central controller that would be able to coordinate the deployment of different protocols amongst several devices in a consistent fashion. Such a controller would receive high-level policy information from a management application, transform it in network-level configuration and apply it to physical or virtual devices. At that point, several other use cases outside of the deployment of IPv6 started to emerge, for example for the control of data center traffic steering, for the creation of tunnels and the provisioning of L3VPN. The group decided to rename its activities under the acronym APONF, for Application Policy on Network Functions, which seemed a more fitting name. The definition of policies by a management application toward a network controller would be at the center of the work for the group. Several group documents were created around this concept. 

When presented at a bar bof during IETF-90 in Toronto, most of the feedback was positive, but the scope of the work was often judged too large in scope. It wasn't clear either how much overlap there was with other IETF groups. A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, but also where deficiencies exist. The two aspects where IETF work seems to be lacking are in the definition of high-level policy language for applications and also in a standard model to describe network topologies at different levels of granularity, or abstraction. Some existing working groups have published work on the latter. For example, the ALTO working group defined a way to describe network functions at different level of granularity using cost maps, but this approach does not seem practical for the description of complex network topologies to and from a central controller. A topology draft exists in the I2RS group, but it is very centered around routing protocols and L2-L3 links. 

The group has recently renamed its activities under the SUPA (Shared Unified Policy Automation) acronym with the intention of defining a standard way to push policies to a central controller. It appears, however, that in order to define such policies, the definition of a standard multi-layer model for the description of networks of all types would be desirable. Therefore the initial work for the SUPA group would be to select an existing modeling language and define a clear multi-layer model able to describe network or service information at any level of granularity or complexity.
--------------

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: [email-masked]
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA really belongs in OPS. I've requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect that.

If I might offer some friendly advice, several ADs are fairly confused about the relationship between openv6, APONF, and SUPA. If you could put together a short paragraph that's something like "we started openv6 to do X, then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different direction with SUPA because of Z", that would be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the description at https://www.ietf.org/mailman/listinfo/supa more understandable for people who haven't been following the work - if you intend to charter a working group, you'll want people to understand what you're proposing.

You should probably keep in mind that people who talk over a long period of time are likely to develop a shared understanding that people who weren't involved don't understand clearly. If there's a smart newcomer who could look over problem statements, proposed charters and see what's not clear to newcomers, that would likely be helpful as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, where all ADs lurk sooner or later ...

Spencer

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

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 18 Sep 2014 03:38:37 +0000

Dear Tina, Dear all,
Thank you very much for sending the updated charter. In principle I agree with these updated, but I have some comments:
Comment_1: What you mean by the term "applications"? Are you referring to "end user applications"?
According to discussions that we have had in APONF, I believe that we had decided to work on an interface between network services, which are enhanced OSS type of services and the controller and NOT between end user applications and the controller.

Comment_2: The charter does not include any information about the "policy automation" that needs to be supported by this activity, see title of this activity.
IMO, the charter can include text, similar to the below:

"A network graph includes application based policies, which are actions and access policies generated by network service systems to map the network  graph instance into specific network management policies, i.e., into physical or virtualized network components.
 Such application based demands are:
            *) Configuration types:
                 o) request to dynamically configure e.g., (virtualized) L2VPN, a (virtualized L3VPN),
                  a service topology, the  relationships between datacentres
                o) request to place the configuration, e.g., a service topology on physical locations, e.g.,
                    on VMs (virtual Machines)

           *) Data plane types:
                o) request to steer a traffic flow
                 o) request prioritize a traffic flow
                 o) request to encapsulate/de-capsulate a traffic flow
                 o) request block or admit a traffic flow

             *) Control plane / Routing plane types:
                 o) request to change the routing state on a service or network function

As starting point SUPA will only focus on application based demands used for configuration purposes. "

Comment_3: the charter does not include any information about authentication and authorization support.
We could add the following bullet into the work items:
o) The definition on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

Comment_4: the charter does not explain what is out of scope. You may add:
"The following items are out of the SUPA scope:

o) specification of the network management and controlling policies and their associated device configuration models"

Comment_5: there is not a one to one mapping between the work items and the milestones. Moreover, there are too many milestones that are focusing on producing Informational RFCs.
You may remove some of the bullets and add new ones. The Milestones section can then become:
Milestones:
-   Produce 'Problem Statement and Use Cases' as an Informational RFC.

-   Produce a document specifying the  model for a generic multi-layer network graph, as an Informational RFC.

-   Produce several documents describing different levels of abstract views using the network graph model defined above, including physical view, logical view, layer-3 view, configuration view, performance probing view, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering, as Protocol Specifications' Standards Track RFCs.

-   Produce a document on SUPA NETCONF/YANG (or RESTCONF/YANG) Protocol Specification' Standards Track RFC.

-    Produce a document that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC.

Best regards,
Georgios

:
From: Tina TSOU <[email-masked]<mailto:[email-masked]>>
Date: September 15, 2014 at 1:57:32 PM PDT
To: Spencer Dawkins <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
Dear Spencer, Benoit et al,

* SUPA draft charter:
--------------

Target Area: OPS

------------

When presented at a bar bof during IETF-90 in Toronto, most of the feedback was positive, but the scope of the work was often judged too large in scope. It wasn't clear either how much overlap there was with other IETF groups. A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, but also where deficiencies exist. The two aspects where IETF work seems to be lacking are in the definition of high-level policy language for applications and also in a standard model to describe network topologies at different levels of granularity, or abstraction. Some existing working groups have published work on the latter. For example, the ALTO working group defined a way to describe network functions at different level of granularity using cost maps, but this approach does not seem practical for the description of complex network topologies to and from a central controller. A topology draft exists in the I2RS group, but it is very centered !
around ro
uting protocols and L2-L3 links.

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Spencer

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

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

---

From: Zhen Cao <[email-masked]>
Date: Mon, 22 Sep 2014 14:13:06 +0200

Hello Tina and everybody,

I have some comments about the scope of SUPA, as a newly coming reader.
See the comments in line.

Best regards,
zhen

> Network operators are faced with networks of increasing size and
> complexity while trying to improve their quality and availability, as more
> and more services depend on them. Programmatic ways to configure networks,
> often  called software-defined, are considered by many network operators in
> order to shift the balance in their favor.
>
> Automation of configuration may provide significant improvements in
> configuration agility, error detection and uptime for operators. However
> the real value behind central configuration schemes lies within the
> possible simplification through abstraction provided by such systems to
> applications running above them (on the so-called northbound side).
> Well-designed abstractions are able to provide a wide range of granularity
> for various applications needs, from the lower-level physical network to
> high-level application services.
>
>
After the first two paragraph, I am really expecting a full introduction of
SUPA, especially what the four-letter abbreviation means physically.

> Although several organizations outside of the IETF have defined various
> schemes for the configuration of network devices and specific network
> controllers, none of them offer a vendor-neutral standardized way for
> applications to transmit their needs to controllers. The SUPA (Shared
> Unified Policy Automation) working group will work on the definition of
> such as standardized interface for applications to communicate with network
> controllers of all types.
>
>
> The interface definitions will be based on the concept of network graph,
> an entity describing an arbitrary topology of nodes and links at any level
> of abstraction and granularity.
>
> 'Any level of abstraction' is very aggressive to me, good to you guys?
What's the level of abstraction will the group focus on?

> Such a graph may describe, for example, a physical topology, a L2 network,
> a service topology or the relationships between datacenters. Although some
> IETF working groups have started work relating to the description of
> various topologies such as I2RS (L3 and routing topologies), ALTO (cost
> maps), SFC (service chain), none of these groups aim at offering a truly
> generic multi-layer and abstract topology for standard northbound
> configuration.
>
How about moving the easier items to the front, e.g. the problem statement
and requirement. Normally these are the prerequisite for any chartered
technical items, basic on which the definition/specification/choice making
work can kick-off.  Btw, the five items charter also seems aggressive too.

>
> 1) Choice of a modeling language used by the group to describe the network
> graph. Existing modeling languages such as YANG will be considered for this
> purpose unless no suitable one is found.
>
> 2) Choice of a transport protocol for the modeling language mentioned
> above. The group will re-use a protocol already defined as a transport for
> the modeling language, such as NETCONF or RESTCONF in the case of YANG.
>
> 3) The definition of a standardized model for a network topology graph.
> This model may be used to describe topologies at any functional layer, from
> physical networks to network services and higher abstractions. The nodes of
> this graph may describe physical nodes as well as virtualized ones.
>
> 4) The definition and standardization of a number of basic abstracted
> models using network graphs. These might include, but are not limited to,
> L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of IPv6
> transition mechanism and their enforcement to users.
>
> -   Produce a requirement document describing the desired properties of an
> abstract multi-layer network graph definition.
>
> -   Produce a gap analysis of existing modeling language, their
> characteristics, possible transport protocols and how they compare to the
> SUPA requirements.
>
> -   Produce several documents describing different levels of abstract
> views using the network graph model defined above, including physical view,
> logical view, layer-3 view, configuration view, performance probing view,
> service view and other such as L3VPN, L2VPN, datacenters and traffic
> engineering.
>
> ------------
>
>
> Most IETF working groups are formed in the interest of solving some actual
> real-world problem from network operators, developers or manufacturers and
> the initial work from the OPENv6 group was no exception. Some operators saw
> a common interest in defining a common approach for the deployment of IPv6
> transition tools. Although the preferred way of deploying IPv6 remains by
> dual-stacking, several operators have deployed additional transition tools
> such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with
> the intent of speeding up or to provide more flexibility in their IPv6
> services. Each of these protocols presents its own set of deployment
> challenges and failure modes for users, either because of unsupported
> applications, partial implementations in some off-the-shelf devices such as
> home routers or some limitations of the protocols themselves to name a few
> cases.
>
> The fact these protocols are often deployed with techniques targeting the
> extension of IPv4 service, such as Carrier Grade NAT, making their
> deployment even more complex, especially when targeting minimal end-user
> impact. Although some approaches in solving this were proposed, for example
> in RFC6264, the market hasn't seen the advent of configurable CGN devices
> or adaptive home gateways. The only solution for operators is to have an
> agile way to provision rapidly and easily any type of IPv6 or IPv4 service
> depending of the specific needs of each end-user and their device. These
> changes must be performed with respect to the operator existing policies
> regarding the network, billing, security and other constraints.
>
> While exploring these issues, it became clear the best way to address them
> would be to use a central controller that would be able to coordinate the
> deployment of different protocols amongst several devices in a consistent
> fashion. Such a controller would receive high-level policy information from
> a management application, transform it in network-level configuration and
> apply it to physical or virtual devices. At that point, several other use
> cases outside of the deployment of IPv6 started to emerge, for example for
> the control of data center traffic steering, for the creation of tunnels
> and the provisioning of L3VPN. The group decided to rename its activities
> under the acronym APONF, for Application Policy on Network Functions, which
> seemed a more fitting name. The definition of policies by a management
> application toward a network controller would be at the center of the work
> for the group. Several group documents were created around this concept.
>
> When presented at a bar bof during IETF-90 in Toronto, most of the
> feedback was positive, but the scope of the work was often judged too large
> in scope. It wasn't clear either how much overlap there was with other IETF
> groups. A better analysis of this aspect in the following weeks revealed
> some level of overlap with other groups, but also where deficiencies exist.
> The two aspects where IETF work seems to be lacking are in the definition
> of high-level policy language for applications and also in a standard model
> to describe network topologies at different levels of granularity, or
> abstraction. Some existing working groups have published work on the
> latter. For example, the ALTO working group defined a way to describe
> network functions at different level of granularity using cost maps, but
> this approach does not seem practical for the description of complex
> network topologies to and from a central controller. A topology draft
> exists in the I2RS group, but it is very centered !
> around ro
> The group has recently renamed its activities under the SUPA (Shared
> Unified Policy Automation) acronym with the intention of defining a
> standard way to push policies to a central controller. It appears, however,
> that in order to define such policies, the definition of a standard
> multi-layer model for the description of networks of all types would be
> desirable. Therefore the initial work for the SUPA group would be to select
> an existing modeling language and define a clear multi-layer model able to
> describe network or service information at any level of granularity or
> complexity.
> --------------
>
>
> Thank you,
> Tina
>
> From: Supa [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Spencer Dawkins
> together a short paragraph that's something like "we started openv6 to do
> X, then we realized we needed to do Y so we proposed APONF, and after
> discussions in Toronto, we chose a different direction with SUPA because of
> Z", that would be very helpful.
>
> weren't involved don't understand clearly. If there's a smart newcomer who
> could look over problem statements, proposed charters and see what's not
> clear to newcomers, that would likely be helpful as well.
>

---

From: Georgios Karagiannis <[email-masked]>
Date: Mon, 22 Sep 2014 13:27:08 +0000

Hi Zhen,

Thank you very much for the comments.

In the next version of the charter, we will:
o) emphasize the main goal of SUPA:

   The main goal of SUPA is to provide a way for applications to specify
   policies to the network infrastructure using a simplified view of
   network. This can be realized by: (1) modeling the network
   infrastructure as an simplified network graph using a modeling
   language such as YANG (2) transporting model
   instances either using NETCONF or RESTCONF and (3) providing guidelines on
   mapping policies to attributes of the network graphs.

o) emphasize that as starting point, for applications, we will focus only on network services

o) emphasize that we will focus on policy and data models that are able to provide enough details on the used network and service topology.

o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required.

Best regards,
Georgios

From: Supa [mailto:[email-masked]] On Behalf Of Zhen Cao
Sent: Monday, September 22, 2014 2:13 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

I have some comments about the scope of SUPA, as a newly coming reader.  See the comments in line.

Best regards,
zhen

After the first two paragraph, I am really expecting a full introduction of SUPA, especially what the four-letter abbreviation means physically.

The interface definitions will be based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of abstraction and granularity.
'Any level of abstraction' is very aggressive to me, good to you guys?  What's the level of abstraction will the group focus on?

Such a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology for standard northbound configuration.

How about moving the easier items to the front, e.g. the problem statement and requirement. Normally these are the prerequisite for any chartered technical items, basic on which the definition/specification/choice making work can kick-off.  Btw, the five items charter also seems aggressive too.

------------

Thank you,
Tina

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Spencer

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 15:41:45 +0200

> o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required.

I am wondering what this is or why this would be needed. At the
charter level, you may need to talk about defining data models to
express policy. I do not see why that would need to enhancements of
YANG's usage of xpath.

/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: Georgios Karagiannis <[email-masked]>
Date: Mon, 22 Sep 2014 20:17:35 +0000

Hi Juergen,

Okay, thanks for your recommendation!

Best regards,
Georgios

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 3:42 PM
To: Georgios Karagiannis
Cc: Zhen Cao; Tina TSOU; [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

> o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required.

I am wondering what this is or why this would be needed. At the charter level, you may need to talk about defining data models to express policy. I do not see why that would need to enhancements of YANG's usage of xpath.

/js

---

From: Tina TSOU <[email-masked]>
Date: Tue, 23 Sep 2014 07:13:53 +0000

Dear all,

Hope this version of draft charter address most of the comments from the list.

------

Automating the way of exposing a view of the network to applications may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through models provided by such systems to applications and network services running above them (on the so-called northbound side). Well-designed models are able to provide a wide range of granularity for various applications and network services needs, from the lower-level physical network to high-level application services. 

Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications and network services to communicate with network controllers of all types.

The specification of the interface towards end user apllications is initially not in the scope of SUPA. In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems. 
Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network. 

The main goal of SUPA is to provide a way for applications and for network services to specify SHARED application based POLICIES to the network infrastructure using a simplified view of the network. This can be realized by: 
(1) modeling the network infrastructure as an simplified network graph using a modeling language such 
as YANG, (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs.

Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface.
SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible.
In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components. 

1) The definition of a standardized model for a network graph, using YANG. This model may be used to describe topologies at any functional layer, from physical networks to network services. 
Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible.

2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.  

3) Guidelines on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

4) Guidelines for automatic mapping policies to attributes of the network graphs.

The following items are out of the SUPA scope:

o) specification of the network management and controlling policies and their associated device configuration models

Milestones:

o) Produce 'Problem Statement and Use Cases' as an Informational RFC.

o) Produce a document specifying the YANG models for a generic multi-layer network graph, as Protocol Specification' Standards Track RFC.

o) Produce several documents describing different views of a communication network by using the network graph model defined above, which includes policy and data models, as Protocol Specifications' Standards Track RFCs.

o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or RESTCONF/YANG) containers, as Protocol Specification' Standards Track RFC.
    
o) Produce a document that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC.

o) Produce a document that provides the guidelines for for automatic mapping policies to attributes of the network graphs.

-----------

Thank you,
Tina

-----Original Message-----
From: Georgios Karagiannis 
Sent: Tuesday, September 23, 2014 4:18 AM
To: Juergen Schoenwaelder
Cc: Zhen Cao; Tina TSOU; [email-masked]
Subject: RE: [Supa] Area hand-off, and some friendly advice ...

Hi Juergen,

Best regards,
Georgios

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, September 22, 2014 3:42 PM
To: Georgios Karagiannis
Cc: Zhen Cao; Tina TSOU; [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Sep 2014 15:38:36 +0200

> Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applicat…

I am lost here. Thanks for trying to explain shared and unified but
this text does not explain things to me. I also have no clue what a
'classified' policy model is. Perhaps it is a phrasing issue, I do not
know.
 
> as YANG, (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs.

I am still unclear what "shared" here implies/means.

I also learn from this text that policies are not expressed as
attributes of network graphs. Why is this so? Is your idea that a
policy exists between say to endpoints of a virtual link and the
attributes are the concrete properties of the collection of links and
nodes making up the virtual link? Are these guidelines expected to go
N layers deep or do we stop somewhere (e.g. when we leave the
"territory of IETF protocols")? If this is a correct understanding of
the intention, I think this should be clarified. If this is not a
correct understanding of the intention, this must be clarified. ;-)

> In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then map…

Here I get lost again. Here it says "policies may be defined and
applied to a network graph". Above, you wrote "guidelines on
AUTOMATICALLY mapping policies to attributes of the network graphs".

Here you write "They are then mapped from the network graph instance
to specific network management policies toward network
components". How does that related to your previous text? Is it useful
to call device configurations policies as well?0

> Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible.

If you shoot for a generic model and the other models are indeed not
generic (not sure yet this will be true but too early to tell), then
how can you incorporate them? Perhaps it is more honest to say that
mappings to other network topology data models will be defined or
something like that.

> 2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, impleme…

Again, I consider data centers to be problematic. Is your idea to
leave it in on purpose so that people have something to argue against
and you finally take it out later?

> o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or RESTCONF/YANG) containers, as Protocol Specification' Standards Track RFC.

I have no clue what this would be or why it is needed. A YANG data model
does not need any extra definitions to be usable.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Sep 2014 00:57:45 +0200

Tina, all,

To make sure this comment is not lost at the end of this email, let me 
make it upfront. I invite you to submit a BoF request to make your case.
Note: the deadline is Sept 26th.

Let's start from this figure, where NE= Network Element
             ---------------------
             | applications   |
             ---------------------
                          |                               <--- service 
YANG models  /NETCONF interface
             ---------------------
             |   controller     |               <---  mapping services 
to topology
             ---------------------
                 |       |        |                    <--- 
device/feature specific YANG models / NETCONF interface
             NE1    NE2   NEn

What can the IETF possibly standardize?
1. Service YANG models  /NETCONF? Yes, for sure, and we should do this 
full speed
2. Mapping services to topology? Potentially, but that's not an easy task
3. service YANG models  /NETCONF? I'm not convinced we could standardize 
them, as they are operators specific, and will be evolving along the 
time. There are many different ways to configure a VPN, for example.

See in-line
> Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to controllers.
Isn't it simply because the industry has not standardized their 
services?  See above.
> The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications and network services to communicate with network controllers of all types.
What is a standardized interface?
Is "service YANG models  /NETCONF (or potentially RESTCONF)"? Or is it 
something else?
>
> The specification of the interface towards end user apllications is initially not in the scope of SUPA.
Here you lost me.
Which interface do you mean in figure above?

> In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems.
I'm afraid I don't understand (like Jürgen)
> as YANG,

> (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs.
>
So basically, you "just" want a topology database ...
http://tools.ietf.org/html/draft-clemm-netmod-yang-network-topo-01
http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/
... and a way to map services to it.
The topology is kind of easy, the mapping is way harder!
> 2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, impleme…
Are these examples of SHARED and UNIFIED policies?

Regards, Benoit (OPS AD)

---

From: Georgios Karagiannis <[email-masked]>
Date: Wed, 24 Sep 2014 06:00:08 +0000

Hi Benoit,

Thanks for your comments!
Please see in line.

>From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
>Sent: Wednesday, September 24, 2014 12:58 AM
>To: Tina TSOU; Georgios Karagiannis; Juergen Schoenwaelder
>Cc: Zhen Cao; [email-masked]

>To make sure this comment is not lost at the end of this email, let me make it upfront. I invite you to submit a BoF >request to make your case.

             ---------------------
             | applications   |
             ---------------------
                          |                               <--- service 
             ---------------------
             ---------------------
                 |       |        |                    <--- 
             NE1    NE2   NEn

Georgios: Please note that we are referring to the following figure:
             ---------------------------------------  
             | applications                        |
             ---------------------------------------
                       |  <---end use. Appl.   |
             ---------------------             |<---end use. Appl.   
             | enhanced OSS      |             |
             ---------------------             |
                      |   <--- network service |
YANG models  /NETCONF interface                |
             --------------------------------------
             |   controller                       |               <---  mapping network services 
to topology
             --------------------------------------
                 |       |        |                    <--- 
device/feature specific YANG models / NETCONF interface
             NE1    NE2   NEn

What can the IETF possibly standardize?
1. Service YANG models  /NETCONF? Yes, for sure, and we should do this full speed 2. Mapping services to topology? Potentially, but that's not an easy task 3. service YANG models  /NETCONF? I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example.

Georgios: According to the provided figure: 1) need to work on network service Yang models, 2 mapping network services to topology, 3. Device/feature specific Yang Models, 4) end user specific Yank Models (out of scope). The interface between end user applications and a controller, and interface between end user application and enhanced OSS, are also out of scope.

Regarding your comment, " I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example." Were you referring to:
3. Device/feature specific Yang Models?

> SUPA (Shared Unified Policy Automation) Target Area: OPS
>
>

Georgios: yes they are: network service YANG models  /NETCONF (or potentially RESTCONF)"

Here you lost me.

Georgios: Thanks for the suggestion, the text needs to be rephrased, see below:
Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming from a bundle of applications that impose similar requirements on the communication network.

> In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then map…

Georgios: the above text is not clear. Therefore, I am rephrasing it:
=============================================
The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and AUTOMATICALLY feed network management and controlling policies. This can be realized by:

(1) modeling the network graph, which among others include policy models, data models and application based policies, using YANG, 

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network graphs in a secure and efficient manner between network service systems and network management and controlling systems, 

(3) providing guidelines on mapping attributes of network graphs provided by network service systems into specific network management and controlling policies.

=================================

> Are these examples of SHARED and UNIFIED policies?

Georgios: yes, that is what we mean.

Regarding work items, I agree that they were not clear. 
Below I am rephrasing the work items and milestones:

=======================
Work items related to SUPA include:

o) specify the network graph based on YANG policy and data models

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network graphs between network service systems and network management and controlling systems

o) provide guidelines for mechanisms that can dynamically and automatically map attributes, including application based policies, of network graphs into specific network management and controlling policies
 
o) document how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

Milestones:

    I-D 'Problem Statement and Use Cases' as an Informational RFC.

    I-D 'Guidelines on mapping network graphs into specific network  
    management and controlling policies' as an Informational RFC.

    I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and 
    authorization mechanisms to achieve security protection and isolation' 
    as an Informational RFC.

    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol 
    Specification' Standards Track RFC.

=====================

Georgios: Regarding your concern about mapping, yes I agree.
Please note that we aim to generate guidelines on mapping of the network graphs into specific network  
    management and controlling policies'.

Regards, Benoit (OPS AD)

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Sep 2014 11:40:54 +0200

Hi Georgios,
> Georgios: Please note that we are referring to the following figure:
It's not obvious what an "enhanced OSS" is?
> Georgios: According to the provided figure: 1) need to work on network service Yang models, 2 mapping network services to topology, 3. Device/feature specific Yang Models, 4) end user specific Yank…
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

> 3. Device/feature specific Yang Models?
No, the service YANG models
> Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming fro…
I still don't understand what "UNIFIED and SHARED" mean.
> Georgios: the above text is not clear. Therefore, I am rephrasing it:
"between network service systems and network management and controlling 
system". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Regards, Benoit

---

From: Georgios Karagiannis <[email-masked]>
Date: Wed, 24 Sep 2014 11:29:34 +0000

Hi Benoit,

Thank you for your comments.
Please see in line,

From: Supa [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, September 24, 2014 10:41 AM
To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,

Please see in line.

             | applications                        |

                       |  <---end use. Appl.   |

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

to topology

                 |       |        |                    <---

             NE1    NE2   NEn

Georgios: it relates to the system that runs network services. These services are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network.

It relates to the interface between the network service system (enhanced OSS in the above figure.
Please note that we say that we initially only focus on this interface, in order to narrow down the scope of this activity

However, if there are supports that think we should initially focus also on the interface between end user application and controller we will also include this interface in the scope.

Georgios: I see, but we can work on YANG models that can be used for a number of main network services, which are essential for operators and that they would like to have them standardized.

See in-line

Dear all,

------

Georgios: What we want to say is that there are applications that impose similar requirements on the communication network. For each group of such bulk of applications a network service can be defined that can be represented by a service policy model (i.e., its actions and constraints).

Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming from a bundle of applications that impose similar requirements on the communication network.
I still don't understand. what "UNIFIED and SHARED" mean.

Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the service policy model is generated, since it groups and it unifies and shares the similar requirements imposed by a bulk of applications.

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network graphs in a secure and efficient manner between network service systems and network management and controlling systems,
"between network service systems and network management and controlling system". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Georgios: In the figure, the enhanced OSS represents the network service system and the controller represents the network management and controlling system.
In this context, network services can be used to provide the required  configuration and application programming interfaces to service developers. Subsequently, a network service can use the application based demands (for actions and constraints) and possibly update its associated network service  attributes. Examples of network services that can modify  the network service attributes are for example, L3VPN configuration and IPv6 transitions.
For each network service instance a network graph needs to be generated and maintained.
The up to date network graph needs to (1) be communicated between the  network service systems and the network   management and controlling systems, (2) map the attributes of the network service graph into specific network management policies.

Best regards,
Georgios

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2014 17:25:47 +0200

Hi,

I can't decipher this. Can people please configure their email clients
such that they do good old quotation instead of using different fonts
and colors that are only visible in HTML?

Thanks,

/js

---

From: Georgios Karagiannis <[email-masked]>
Date: Wed, 24 Sep 2014 16:22:56 +0000

Hi Juergen,

Thank you very much!
Your comments are noted!
Please see in line!

The text without > is the text that I sent during my last email to Benoit!

Best regards,
Georgios'

> Sent: Wednesday, September 24, 2014 4:26 PM
> To: Georgios Karagiannis
> Cc: Benoit Claise; Tina TSOU; Zhen Cao; [email-masked]
> I can't decipher this. Can people please configure their email clients such
> that they do good old quotation instead of using different fonts and colors
> that are only visible in HTML?
> 
> Thanks,
> 
> /js
> 
 Hi Benoit,

> > Georgios: it relates to the system that runs network services. These
> services are enhanced Operational Support System (OSS) like services that help
> a communication service provider to monitor, control, analyze and manage a
> communication network.
> >
> >
> >
> > Georgios: According to the provided figure: 1) need to work on network
> service Yang models, 2 mapping network services to topology, 3. Device/feature
> specific Yang Models, 4) end user specific Yank Models (out of scope). The
> interface between end user applications and a controller, and interface
> between end user application and enhanced OSS, are also out of scope.

>  o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
>  used to securely and efficiently distribute up to date (fresh) network
>  graphs between network service systems and network management and
> controlling systems

Georgios: It relates to the interface between the network service system (enhanced OSS
 and controller in the above figure.

 Please note that we say that we initially only focus on this
interface, in order to narrow down the scope of this activity

 However, if there are supports that think we should initially focus also on
the interface between end user application and controller we will also include
this interface in the scope.

> >
> >
> >
> >
> >
> >
> >
> > Regarding your comment, " I'm not convinced we could standardize them, as
> they are operators specific, and will be evolving along the time. There are
> many different ways to configure a VPN, for example." Were you referring to:
> >

 Georgios: I see, but we can work on YANG models that can be used for a
number of main network services, which are essential for operators and that
they would like to have them standardized.
> > In particular, as starting point, SUPA will only focus on network services,
> which are enhanced Operational Support System (OSS) like services that help a
> communication service provider to monitor, control, analyze and manage a
> communication network. The systems that are runniung such network services are
> denoted in this document as Network Service Systems.
> >
> > Each network service can be represented by a classified application based
> POLICY model, since it can model the group of demands which are SHARED and
> UNIFIED and are coming from a bundle of applications that impose similar
> requirements on the communication network.
> >
Georgios: What we want to say is that there are applications that impose
similar requirements on the communication network. For each group of such bulk
of applications a network service can be defined that can be represented by a
service policy model (i.e., its actions and constraints).
> > Each network service can be represented by an application based POLICY model,
> which is UNIFIED and SHARED, since it can model the group of demands (i.e,
> actions and constraints) that are coming from a bundle of applications that
> impose similar requirements on the communication network.

Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the
service policy model is generated, since it groups and it unifies and shares
the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (2) transporting model instances either using NETCONF or RESTCONF and (3)
> providing guidelines on AUTOMATICALLY mapping policies to attributes of the
> network graphs.
> >
> >
> >
> > Although some IETF working groups have started work relating to the
> description of various topologies such as I2RS (L3and routing topologies),
> ALTO (cost maps), SFC (service chain), none of these groups aim at offering
> truly generic topology models for the standard northbound interface.
> >
> > SUPA will work on defining interfaces based on the concept of network graph,
> an entity describing an arbitrary topology of nodes and links at any level of
> granularity. Such a graph may describe, for example, a physical topology, a
> service topology or the relationships between datacenters. Any network
> topology data models or policy models that have been defined (or are being
> defined) within the IETF will be reused in SUPA as much as possible.
> >
> > In addition to the above, policies may be defined and applied to a network
> graph. These application based policies are actions or constraints generated
> by Network Service Systems. They are then mapped from the network graph
> instance into specific network management policies toward network components.
> >
> >
> >
> >
> >
> > The main goal of SUPA is to provide application based policies and means to
> model and program the abstract view of network infrastructure and service
> function interdependencies in order to support and AUTOMATICALLY feed network
> management and controlling policies. This can be realized by:
> >
> >
> >
> > (1) modeling the network graph, which among others include policy
> > models, data models and application based policies, using YANG,
> >
> >
> >
> > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> > date (fresh) network graphs in a secure and efficient manner between network
> service systems and network management and controlling systems, "between
> network service systems and network management and controlling system".

> Whatare those? I don't see them in your figure.

 Georgios: In the figure, the enhanced OSS represents the network service
system and the controller represents the network management and controlling
system. In this context, network services can be used to provide the required
configuration and application programming interfaces to service developers.
Subsequently, a network service can use the application based demands (for
actions and constraints) and possibly update its associated network service
attributes. Examples of network services that can modify  the network service
attributes are for example, L3VPN configuration and IPv6 transitions.
 For each network service instance a network graph needs to be generated andmaintained.
The up to date network graph needs to (1) be communicated between the
network service systems and the network   management and controlling systems,
(2) map the attributes of the network service graph into specific network management policies.

Best regards,
 Georgios

> > Georgios: it relates to the system that runs network services. These
> services are enhanced Operational Support System (OSS) like services that help
> a communication service provider to monitor, control, analyze and manage a
> communication network.
> >
> >
> >
> > Georgios: According to the provided figure: 1) need to work on network
> service Yang models, 2 mapping network services to topology, 3. Device/feature
> specific Yang Models, 4) end user specific Yank Models (out of scope). The
> interface between end user applications and a controller, and interface
> between end user application and enhanced OSS, are also out of scope.
> > o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
> > used to securely and efficiently distribute up to date (fresh) network
> > graphs between network service systems and network management and
> > controlling systems
> >
> > Please note that we say that we initially only focus on this
> > interface, in order to narrow down the scope of this activity
> >
> > However, if there are supports that think we should initially focus also on
> the interface between end user application and controller we will also include
> this interface in the scope.
> >
> >
> >
> >
> >
> >
> >
> > Regarding your comment, " I'm not convinced we could standardize them, as
> they are operators specific, and will be evolving along the time. There are
> many different ways to configure a VPN, for example." Were you referring to:
> >
> > Georgios: I see, but we can work on YANG models that can be used for a
> number of main network services, which are essential for operators and that
> they would like to have them standardized.
> >
> >
> >
> >
> >
> >
> > See in-line
> >
> > Dear all,
> >
> >
> >
> > In particular, as starting point, SUPA will only focus on network services,
> which are enhanced Operational Support System (OSS) like services that help a
> communication service provider to monitor, control, analyze and manage a
> communication network. The systems that are runniung such network services are
> denoted in this document as Network Service Systems.
> >
> > Each network service can be represented by a classified application based
> POLICY model, since it can model the group of demands which are SHARED and
> UNIFIED and are coming from a bundle of applications that impose similar
> requirements on the communication network.
> >
> > Georgios: What we want to say is that there are applications that impose
> similar requirements on the communication network. For each group of such bulk
> of applications a network service can be defined that can be represented by a
> service policy model (i.e., its actions and constraints).
> >
> >
> >
> >
> >
> > Each network service can be represented by an application based POLICY model,
> which is UNIFIED and SHARED, since it can model the group of demands (i.e,
> actions and constraints) that are coming from a bundle of applications that
> impose similar requirements on the communication network.
> > Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the
> service policy model is generated, since it groups and it unifies and shares
> the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (2) transporting model instances either using NETCONF or RESTCONF and (3)
> providing guidelines on AUTOMATICALLY mapping policies to attributes of the
> network graphs.
> >
> >
> >
> > Although some IETF working groups have started work relating to the
> description of various topologies such as I2RS (L3and routing topologies),
> ALTO (cost maps), SFC (service chain), none of these groups aim at offering
> truly generic topology models for the standard northbound interface.
> >
> > SUPA will work on defining interfaces based on the concept of network graph,
> an entity describing an arbitrary topology of nodes and links at any level of
> granularity. Such a graph may describe, for example, a physical topology, a
> service topology or the relationships between datacenters. Any network
> topology data models or policy models that have been defined (or are being
> defined) within the IETF will be reused in SUPA as much as possible.
> >
> > In addition to the above, policies may be defined and applied to a network
> graph. These application based policies are actions or constraints generated
> by Network Service Systems. They are then mapped from the network graph
> instance into specific network management policies toward network components.
> >
> >
> >
> >
> >
> > The main goal of SUPA is to provide application based policies and means to
> model and program the abstract view of network infrastructure and service
> function interdependencies in order to support and AUTOMATICALLY feed network
> management and controlling policies. This can be realized by:
> >
> >
> >
> > (1) modeling the network graph, which among others include policy
> > models, data models and application based policies, using YANG,
> >
> >
> >
> > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> > date (fresh) network graphs in a secure and efficient manner between network
> service systems and network management and controlling systems, "between
> network service systems and network management and controlling system". What
> are those? I don't see them in your figure.
> > Georgios: In the figure, the enhanced OSS represents the network service
> system and the controller represents the network management and controlling
> system.
> > In this context, network services can be used to provide the required
> configuration and application programming interfaces to service developers.
> Subsequently, a network service can use the application based demands (for
> actions and constraints) and possibly update its associated network service
> attributes. Examples of network services that can modify  the network service
> attributes are for example, L3VPN configuration and IPv6 transitions.
> > The up to date network graph needs to (1) be communicated between the
> network service systems and the network   management and controlling systems,
> (2) map the attributes of the network service graph into specific network
> management policies.
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> >
> > Regards, Benoit
> 
> --

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 25 Sep 2014 06:07:06 +0000

Hi Benoit,

Based on your comments, I realized that it will be clearer if SUPA should use a three tier architecture instead of a four tier architecture.

I am also proposing to include the following figure in the problem statement draft.

             ---------------------------------------  
             | Applications                        |
             ---------------------------------------
                              |   <--- network service 
                              |        YANG models  /NETCONF interface                
             --------------------------------------
             |   controller                       | <---  mapping network services to topology
             --------------------------------------
                 |       |        |                 <--- device/feature specific YANG models / NETCONF interface
             NE1    NE2   NEn

Please note however, "Applications" represent an entity that generates and maintains network services and is administrated by a service provider."

Regarding the SUPA main goal, work items and milestones, I would like to propose the following:
Please let me know if the below addresses your concerns?

=====================================================
The main goal of SUPA is to provide service specific models that allow applications to request network services to be created/deleted/modified. This can be realized by:
  o) model multiple topologies at different levels of abstraction using a network graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF 

A network service can for example be a virtual link between two endpoints that uses certain properties, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.

SUPA will ensure that In case any specific NETCONF/RESTCONF protocol requirements are identified, they will be communicated in a timely manner to the NETCONF working group. 

Work items for SUPA include:
==========================

2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users.  

3) Provide guidelines for mechanisms that can dynamically and automatically map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

4) Guidelines on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation

Milestones:
===========

o) Produce an I-D  "Problem Statement and Use Cases".

o) Produce an I-D that specifies the YANG models for a generic multi-layer network graph.

o) Produce I-Ds that specify extensions for the generic YANG models defined above for network services that manage virtual links, traffic engineering and implementation of IPv6 transition mechanism and their enforcement to users.

o) Produce an I-D that provides the guidelines for mechanisms that can dynamically and automatically map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.

o) Produce an I-D that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC.

===============================

Best regards,
Georgios

---

From: Qiong <[email-masked]>
Date: Thu, 25 Sep 2014 17:49:39 +0800

Hi Benoit and all,

>From the perspective of an operator, I support this work and believe it’s
meaningful for our network operation and management. I tried to study all
the thread on the mailing list. However, I wonder if I missed something as
I got a little confused reading your two emails.

In your first email, you wrote:

1. **Service YANG models**  /NETCONF? Yes, for sure, and we should do this
full speed 2. Mapping services to topology? Potentially, but that's not an
easy task 3. **service YANG models**  /NETCONF? I'm not convinced we could
standardize them, as they are operators specific, and will be evolving
along the time. There are many different ways to configure a VPN, for
example.

In your second email replying to Georgios, you wrote.

No, the **service YANG models**

There are two “service YANG models” in your first email and you used this
term again in your second email (marked with *). I wonder are you referring
to the same thing, the interface between applications and controller in you
3 layers figure,  by using three of them? As it seems to me that in your
first email, point 1 and point 3 are describing different interfaces with
the same term.

Best wishes

Qiong

China Telecom Beijing Research Institute

*From:* Supa [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Benoit Claise
*Sent:* Wednesday, September 24, 2014 5:41 PM
*To:* Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
*Cc:* Zhen Cao; [email-masked]
*Subject:* Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,

Please see in line.

             | applications                        |

                       |  <---end use. Appl.   |

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

             |   controller                       |               <---
 mapping network services

to topology

                 |       |        |                    <---

             NE1    NE2   NEn

Georgios: According to the provided figure: 1) need to work on network
service Yang models, 2 mapping network services to topology, 3.
Device/feature specific Yang Models, 4) end user specific Yank Models
(out of scope). The interface between end user applications and a
controller, and interface between end user application and enhanced
OSS, are also out of scope.

Regarding your comment, " I'm not convinced we could standardize them,
as they are operators specific, and will be evolving along the time.
There are many different ways to configure a VPN, for example." Were
you referring to:

See in-line

Dear all,

------

In particular, as starting point, SUPA will only focus on network
services, which are enhanced Operational Support System (OSS) like
services that help a communication service provider to monitor,
control, analyze and manage a communication network. The systems that
are runniung such network services are denoted in this document as
Network Service Systems.

Each network service can be represented by a classified application
based POLICY model, since it can model the group of demands which are
SHARED and UNIFIED and are coming from a bundle of applications that
impose similar requirements on the communication network.

Each network service can be represented by an application based POLICY
model, which is UNIFIED and SHARED, since it can model the group of
demands (i.e, actions and constraints) that are coming from a bundle
of applications that impose similar requirements on the communication
network.

(2) transporting model instances either using NETCONF or RESTCONF and
(3) providing guidelines on AUTOMATICALLY mapping policies to
attributes of the network graphs.

Although some IETF working groups have started work relating to the
description of various topologies such as I2RS (L3and routing
topologies), ALTO (cost maps), SFC (service chain), none of these
groups aim at offering truly generic topology models for the standard
northbound interface.

SUPA will work on defining interfaces based on the concept of network
graph, an entity describing an arbitrary topology of nodes and links
at any level of granularity. Such a graph may describe, for example, a
physical topology, a service topology or the relationships between
datacenters. Any network topology data models or policy models that
have been defined (or are being defined) within the IETF will be
reused in SUPA as much as possible.

In addition to the above, policies may be defined and applied to a
network graph. These application based policies are actions or
constraints generated by Network Service Systems. They are then mapped
from the network graph instance into specific network management
policies toward network components.

The main goal of SUPA is to provide application based policies and
means to model and program the abstract view of network infrastructure
and service function interdependencies in order to support and
AUTOMATICALLY feed network management and controlling policies. This
can be realized by:

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to
date (fresh) network graphs in a secure and efficient manner between
network service systems and network management and controlling
systems,

Regards, Benoit

---

From: Tina TSOU <[email-masked]>
Date: Sun, 28 Sep 2014 07:28:00 +0000

Dear Benoit,

Thank you for your kind invitation.

The BoF request has been uploaded to http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Look forward to your further guidance.

Thank you,
Tina

> On Sep 24, 2014, at 6:58 AM, "Benoit Claise" <[email-masked]> wrote:
> 
> Tina, all,
> 
> To make sure this comment is not lost at the end of this email, let me make it upfront. I invite you to submit a BoF request to make your case.
>                         |                               <--- service YANG models  /NETCONF interface
>            ---------------------
>            |   controller     |               <---  mapping services to topology
>            ---------------------
> 1. Service YANG models  /NETCONF? Yes, for sure, and we should do this full speed
> 3. service YANG models  /NETCONF? I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example.
> 
> See in-line
>> Dear all,
>> 
> Isn't it simply because the industry has not standardized their services?  See above.
> Is "service YANG models  /NETCONF (or potentially RESTCONF)"? Or is it something else?
>>