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

From: "Liushucheng (Will)" <[email-masked]>
Date: Thu, 25 Sep 2014 11:35:55 +0000

Hi Benoit,

Below inline please see two pieces of complementary answer from my team (starts with [Will]). Thank you!

Regards,
Will

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

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]<mailto:[email-masked]>
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,

Thanks for your comments!

Please see in line.

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
It's not obvious what an "enhanced OSS" is?

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.
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

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

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.

[Will]: First of all, IMOH, the figures from Benoit and Georgios are not incompatible. From the perspective of controller, they are different latitudes of northband. The application and enhanced OSS in Georgios figure can be put together into an larger application* layer of Benoit's figure. The network graph is proposed to provide network-wide configuration containing the key information for service instances. One example is, for the DDC use case, the network graph contains the key information such as the key node information of the path and the key requirement of traffic steering.

Regarding to the app, management app, end user app here, I want to add something related to the history of this work. At the very beginning, when this work is call APONF before Toronto IETF meeting, the end user app is in the scope. However, there are mainly three reasons that we remove this point:

1.      The confliction with AECON, we discussed with proponents of AECON and to avoid the conflict as at that time they were proposing the interface from end user app to network devices. Later in the IESG meeting in Toronto, we successfully clarified the differences and got the suggestion to focus on management app.

2.      Lars Eggert showed his concerning about the interface between end user app and network devices may lead to security issue.  Kostas Pentikousis also mentioned this to me.

However, these are old stories. During the Toronto BoF, someone also suggested us re-put the end user app into cope. A large app layer containing both end user app and management app may replace the first two layers in the old 4 layers figure. Here, my question is, are you in favor of adding end user app into SUPA scope or not?

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?
No, the service YANG models

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,

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

------

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.

I'm afraid I don't understand (like Jürgen)

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).

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.
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) 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.

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,
"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.
[Will] To modeling service requirement and create service instances, APP needs a view of topology to form network configuration according to the key information of devices topology. This configuration is eventually mapped to the selected network devices according to topology provided by SUPA.

Best regards,
Georgios

Regards, Benoit

---

From: Tina TSOU <[email-masked]>
Date: Fri, 26 Sep 2014 00:50:09 +0000

Dear Benoit et al,

Here comes latest version. The list discussion helps a lot to make it clearer.

=================================================
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor.
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.
Several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, but none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to network 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. In particular, SUPA will focus on service specific models that allow applications to request certain network services to be created/deleted/modified. 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.
Each network service can be represented by a service based POLICY model that can model a group of demands (i.e., actions and constraints) that are being initiated by applications that impose similar requirements on the communication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the way of how the service policy model is generated, since it groups, unifies and shares the similar requirements imposed by a bulk of applications. SUPA will provide guidelines for mechanisms that can dynamically and on an interoperable manner, AUTOMATICALLY map services and policies defined on an abstract topology graph down to more detailed network graphs and specific network management and controlling policies.
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 (1) at offering truly generic topology models for the standard northbound interface, and (2) that an application can communicate with network boxes, such as network controllers, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized 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 network graph describes (1) topologies at different levels of abstraction, (2) the relationships between the abstraction levels and (3) applied service based policy, which are actions and constraints applied on these topologies. SUPA may also define any mappings to any other network topology data models defined within the IETF.
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

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. SUPA will consult with the YANG doctors to ensure that data models follow common practices.

Work items for SUPA include:
============================
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.
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 on an interoperable manner, 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

Deliverables:
=============
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic multi-layer network graph.
o) Produce standards-track RFCs 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 informational RFC that provides the guidelines for mechanisms that can dynamically and on interoperable manner, 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 informational RFC that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC.

Milestones:
===========
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Liushucheng (Will)
Sent: Thursday, September 25, 2014 7:36 PM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Benoit,

Regards,
Will

Hi Benoit,

Hi Georgios,

Hi Benoit,

Please see in line.

             | applications                        |

                       |  <---end use. Appl.   |

             | enhanced OSS      |             |

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

                      |   <--- network service |

to topology

                 |       |        |                    <---

             NE1    NE2   NEn

See in-line

Dear all,

------

Best regards,
Georgios

Regards, Benoit

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Sep 2014 22:05:03 -0400

May I offer a purely editorial rewrite of this? (Mostly just breaking it 
into bite-sized paragraphs):

Many network operators are considering programmatic ways, often called 
software-defined, to configure networks, to shift the balance [of 
costs?] in their favor. Automating the way to expose 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
with 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 service needs, from the lower-level 
physical network to high-level application services. Several 
organizations outside of the IETF have defined various schemes for the 
configuration of network devices and specific network controllers, but 
none of them offer a vendor-neutral standardized way for applications 
and network services to transmit their needs to network controllers. The 
SUPA (Shared Unified Policy Automation) working group will work on the 
definition of such a standardized interface for applications and network 
services to communicate with network controllers of all types.

In particular, SUPA will focus on service specific models that allow
applications to request certain network services to be 
created/deleted/modified. 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. Each network service can be represented by a 
service based POLICY model that can model a group of demands (i.e., 
actions and constraints) that are being initiated by applications that 
impose similar requirements on the communication network.

The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate
to the way the service policy model is generated, since it groups,
unifies and shares the similar requirements imposed by a bulk of 
applications. SUPA will provide guidelines for mechanisms that can 
dynamically and in an interoperable manner, AUTOMATICALLY map services 
and policies defined on an abstract topology graph down to more detailed 
network graphs and specific network management and controlling policies.

Some IETF working groups such as I2RS (L3 and routing topologies), ALTO 
(cost maps), and SFC (service chain) have started work relating to the 
description of various topologies. None of these groups aim:
  (1) at offering truly generic topology models for the standard
      northbound interface, and
  (2) to allow an application to communicate with network
      boxes, such as network controllers, and NEs, developed by
      different vendors.

SUPA will work on defining vendor-neutral standardized 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 network 
graph describes:
  (1) topologies at different levels of abstraction,
  (2) the relationships between the abstraction levels and
  (3) applied service based policy, which is a set of actions and
      constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data
models defined within the IETF.

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) modelling multiple topologies at different levels of abstraction
      using a network graph,
   o) modelling the relationships between the abstraction levels;
   o) transporting model instances using either NETCONF or RESTCONF

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. SUPA will consult with the YANG
doctors to ensure that data models follow common practices.

Work items for SUPA include:
============================
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.

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 mechanisms and their enforcement to users.

3) Provide guidelines for mechanisms that can dynamically and on an
interoperable manner, 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.

Deliverables:
=============
  o) Produce an informational RFC "Problem Statement and Use Cases".
  o) Produce a standards-track RFC that specifies YANG models
     for a generic multi-layer network graph.
  o) Produce standards-track RFCs 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 informational RFC that provides the guidelines
     for mechanisms that can dynamically and on interoperable manner,
     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 informational RFC that provides the guidelines on
     using NETCONF (or RESTCONF) authentication and authorization
     mechanisms to achieve security protection and isolation' as
     an Informational RFC.

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

On 25/09/2014 8:50 PM, Tina TSOU wrote:
> ================================================= SUPA (Shared
> Unified Policy Automation) charter v1.12 Target Area: Operations and
> Management
>
> Programmatic ways to configure networks, often called
> software-defined, are considered by many network operators in order
> to shift the balance in their favor. 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. Several
> organizations outside of the IETF have defined various schemes for
> the configuration of network devices and specific network
> controllers, but none of them offer a vendor-neutral standardized way
> for applications and network services to transmit their needs to
> network 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. In particular, SUPA will focus on
> service specific models that allow applications to request certain
> network services to be created/deleted/modified. 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. Each network
> service can be represented by a service based POLICY model that can
> model a group of demands (i.e., actions and constraints) that are
> being initiated by applications that impose similar requirements on
> the communication network. The terms "UNIFIED" and "SHARED" used in
> the SUPA abbreviation, relate to the way of how the service policy
> model is generated, since it groups, unifies and shares the similar
> requirements imposed by a bulk of applications. SUPA will provide
> guidelines for mechanisms that can dynamically and on an
> interoperable manner, AUTOMATICALLY map services and policies defined
> on an abstract topology graph down to more detailed network graphs
> and specific network management and controlling policies. 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 (1) at
> offering truly generic topology models for the standard northbound
> interface, and (2) that an application can communicate with network
> boxes, such as network controllers, and NEs, developed by different
> vendors. SUPA will work on defining vendor-neutral standardized
> 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 network graph describes (1) topologies at
> different levels of abstraction, (2) the relationships between the
> abstraction levels and (3) applied service based policy, which are
> actions and constraints applied on these topologies. SUPA may also
> define any mappings to any other network topology data models defined
> within the IETF. 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
>
> 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. SUPA will consult with the YANG
> doctors to ensure that data models follow common practices.
>
> Work items for SUPA include: ============================ 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. 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 on an interoperable manner, 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
>
> Deliverables: ============= o) Produce an informational RFC "Problem
> Statement and Use Cases". o) Produce a standards-track RFC that
> specifies YANG models for a generic multi-layer network graph. o)
> Produce standards-track RFCs 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 informational
> RFC that provides the guidelines for mechanisms that can dynamically
> and on interoperable manner, 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 informational RFC that provides the guidelines on using
> NETCONF (or RESTCONF) authentication and authorization mechanisms to
> achieve security protection and isolation' as an Informational RFC.
>
> Milestones: =========== Dec 2014  Initial "Problem Statement and Use
> Cases" WG I-D Feb 2015  Initial "Multi-layer Network Graph YANG
> Model" WG I-D Apr 2015  Initial service specific data model WG I-Ds
> May 2015  Initial "Mapping Guidelines" WG I-D Jun 2015  Submit
> "Problem Statement and Use Cases" I-D to IESG Jul 2015  Initial
> "Authentication and Authorization" WG I-D Sep 2015  Submit
> "Multi-layer Network Graph YANG Model" I-D to IESG Nov 2015  Submit
> service specific data model I-Ds to IESG Feb 2016  Submit "Mapping
> Guidelines" I-D to IESG Apr 2016  Submit "Authentication and
> Authorization" I-D to IESG
>
>
> Thank you, Tina
>
> From: Supa [mailto:[email-masked]] On Behalf Of Liushucheng
> (Will) Sent: Thursday, September 25, 2014 7:36 PM To: Benoit Claise
> Cc: [email-masked] Subject: Re: [Supa] Area hand-off, and some
> friendly advice ...
>
> Hi Benoit,
>
> Regards, Will
> From: Supa [mailto:[email-masked]] On Behalf Of Georgios
> Karagiannis Sent: Wednesday, September 24, 2014 7:30 PM To: Benoit
> Claise; Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> [email-masked]<mailto:[email-masked]> Subject: Re: [Supa] Area
> hand-off, and some friendly advice ...
>
> Hi Benoit,
>
> Thank you for your comments. Please see in line,
>
> Sent: Wednesday, September 24, 2014 10:41 AM To: Georgios
> Karagiannis; Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> [email-masked]<mailto:[email-masked]> Subject: Re: [Supa] Area
> hand-off, and some friendly advice ...
>
> Hi Georgios,
>
> Hi Benoit,
>
>
>
> NE1    NE2   NEn It's not obvious what an "enhanced OSS" is?
>
> 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. Concerning your last sentence.
> I'm confused. What does the following deliverable mean then?
>
> 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
>
> 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.
>
>
>
> [Will]: First of all, IMOH, the figures from Benoit and Georgios are
> not incompatible. From the perspective of controller, they are
> different latitudes of northband. The application and enhanced OSS in
> Georgios figure can be put together into an larger application* layer
> of Benoit's figure. The network graph is proposed to provide
> network-wide configuration containing the key information for service
> instances. One example is, for the DDC use case, the network graph
> contains the key information such as the key node information of the
> path and the key requirement of traffic steering.
>
>
>
> Regarding to the app, management app, end user app here, I want to
> add something related to the history of this work. At the very
> beginning, when this work is call APONF before Toronto IETF meeting,
> the end user app is in the scope. However, there are mainly three
> reasons that we remove this point:
>
> 1.      The confliction with AECON, we discussed with proponents of
> AECON and to avoid the conflict as at that time they were proposing
> the interface from end user app to network devices. Later in the IESG
> meeting in Toronto, we successfully clarified the differences and got
> the suggestion to focus on management app.
>
> 2.      Lars Eggert showed his concerning about the interface between
> end user app and network devices may lead to security issue.  Kostas
> Pentikousis also mentioned this to me.
>
>
>
> However, these are old stories. During the Toronto BoF, someone also
> suggested us re-put the end user app into cope. A large app layer
> containing both end user app and management app may replace the first
> two layers in the old 4 layers figure. Here, my question is, are you
> in favor of adding end user app into SUPA scope or not?
>
>
>
>
>
> 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? No, the service YANG models
>
> 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. 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) 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. 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. [Will] To modeling
> service requirement and create service instances, APP needs a view of
> topology to form network configuration according to the key
> information of devices topology. This configuration is eventually
> mapped to the selected network devices according to topology provided
> by SUPA.
>
> Best regards, Georgios
>
>
>
>
>
> Regards, Benoit
>
>
>
> _______________________________________________ Supa mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/supa
>

---

From: Georgios Karagiannis <[email-masked]>
Date: Fri, 26 Sep 2014 04:34:15 +0000

Hi Tom,

Thank you very much!
We will upload this version in the github!

Best regards,
Georgios

> -----Original Message-----
> From: Supa [mailto:[email-masked]] On Behalf Of Tom Taylor
> Sent: Friday, September 26, 2014 3:05 AM
> To: Tina TSOU; Benoit Claise
> Cc: [email-masked]
> Subject: Re: [Supa] Draft charter v1.12//RE: Area hand-off, and some friendly
> advice ...
> 
> May I offer a purely editorial rewrite of this? (Mostly just breaking it into
> bite-sized paragraphs):
> 
> SUPA (Shared Unified Policy Automation) charter v1.12 Target Area: Operations
> and Management
> 
> software-defined, to configure networks, to shift the balance [of costs?] in
> their favor. Automating the way to expose 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 with possible simplification through models
> provided by such systems to applications and network services running above
> them (on the so-called northbound side).
> 
> various applications and network service needs, from the lower-level physical
> network to high-level application services. Several organizations outside of
> the IETF have defined various schemes for the configuration of network devices
> and specific network controllers, but none of them offer a vendor-neutral
> standardized way for applications and network services to transmit their needs
> to network controllers. The SUPA (Shared Unified Policy Automation) working
> group will work on the definition of such a standardized interface for
> applications and network services to communicate with network controllers of
> all types.
> 
> created/deleted/modified. 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.
> Each network service can be represented by a service based POLICY model that
> can model a group of demands (i.e., actions and constraints) that are being
> initiated by applications that impose similar requirements on the
> communication network.
> 
> The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the
> way the service policy model is generated, since it groups, unifies and shares
> the similar requirements imposed by a bulk of applications. SUPA will provide
> guidelines for mechanisms that can dynamically and in an interoperable manner,
> AUTOMATICALLY map services and policies defined on an abstract topology graph
> down to more detailed network graphs and specific network management and
> controlling policies.
> 
> Some IETF working groups such as I2RS (L3 and routing topologies), ALTO (cost
> maps), and SFC (service chain) have started work relating to the description
> of various topologies. None of these groups aim:
> SUPA will work on defining vendor-neutral standardized 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 network graph describes:
> SUPA may also define any mappings to any other network topology data models
> defined within the IETF.
> 
> requirements are identified, they will be communicated in a timely manner to
> the NETCONF working group. SUPA will consult with the YANG doctors to ensure
> that data models follow common practices.
> 
> 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.
> 
> 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 mechanisms and
> their enforcement to users.
> 
> interoperable manner, automatically map services and policies defined on an
> abstract topology graph down to more detailed network graphs and specific
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation.
> 
> Deliverables:
> =============
> Dec 2014  Initial "Problem Statement and Use Cases" WG I-D Feb 2015  Initial
> "Multi-layer Network Graph YANG Model" WG I-D Apr 2015  Initial service
> specific data model WG I-Ds May 2015  Initial "Mapping Guidelines" WG I-D Jun
> 2015  Submit "Problem Statement and Use Cases" I-D to IESG Jul 2015  Initial
> "Authentication and Authorization" WG I-D Sep 2015  Submit "Multi-layer
> Network Graph YANG Model" I-D to IESG Nov 2015  Submit service specific data
> model I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr 2016
> Submit "Authentication and Authorization" I-D to IESG
> 
> 
> > ================================================= SUPA (Shared Unified
> > Policy Automation) charter v1.12 Target Area: Operations and
> > Management
> >
> > software-defined, are considered by many network operators in order to
> > shift the balance in their favor. Automating the way of exposing a
> > 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. Several organizations outside of the
> > IETF have defined various schemes for the configuration of network
> > devices and specific network controllers, but none of them offer a
> > vendor-neutral standardized way for applications and network services
> > to transmit their needs to network 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. In
> > particular, SUPA will focus on service specific models that allow
> > created/deleted/modified. A network service can for example be a
> > virtual link between two endpoints that uses certain properties,
> > their enforcement to users. Each network service can be represented by
> > a service based POLICY model that can model a group of demands (i.e.,
> > impose similar requirements on the communication network. The terms
> > "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the
> > way of how the service policy model is generated, since it groups,
> > dynamically and on an interoperable manner, AUTOMATICALLY map services
> > and policies defined on an abstract topology graph down to more
> > detailed network graphs and specific network management and
> > controlling policies. 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 (1) at offering truly generic topology models for the
> > standard northbound interface, and (2) that an application can
> > communicate with network boxes, such as network controllers, and NEs,
> > developed by different vendors. SUPA will work on defining
> > vendor-neutral standardized interfaces based on the concept of network
> > at any level of granularity. Such a network graph describes (1)
> > topologies at different levels of abstraction, (2) the relationships
> > between the abstraction levels and (3) applied service based policy,
> > which are actions and constraints applied on these topologies. SUPA
> > may also define any mappings to any other network topology data models
> > defined within the IETF. 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,
> > This model may be used to describe topologies at any functional layer,
> > from physical networks to network services. 2) The definition and
> > standardization of a number of basic policy and data models using
> > Cases" WG I-D Feb 2015  Initial "Multi-layer Network Graph YANG Model"
> > WG I-D Apr 2015  Initial service specific data model WG I-Ds May 2015
> > Initial "Mapping Guidelines" WG I-D Jun 2015  Submit "Problem
> > Statement and Use Cases" I-D to IESG Jul 2015  Initial "Authentication
> > and Authorization" WG I-D Sep 2015  Submit "Multi-layer Network Graph
> > YANG Model" I-D to IESG Nov 2015  Submit service specific data model
> > I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr
> > 2016  Submit "Authentication and Authorization" I-D to IESG
> >
> >
> > Thank you, Tina
> >
> > Cc: [email-masked] Subject: Re: [Supa] Area hand-off, and some friendly
> > advice ...
> >
> > Hi Benoit,
> >
> > [email-masked]<mailto:[email-masked]> Subject: Re: [Supa] Area hand-off,
> > and some friendly advice ...
> >
> > Hi Benoit,
> >
> > Sent: Wednesday, September 24, 2014 10:41 AM To: Georgios Karagiannis;
> > Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> > [email-masked]<mailto:[email-masked]> Subject: Re: [Supa] Area hand-off,
> > and some friendly advice ...
> >
> > Hi Georgios,
> >
> > Hi Benoit,
> >
> >
> >
> > 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. Concerning your last sentence.
> > used to securely and efficiently distribute up to date (fresh) network
> > graphs between network service systems and network management and
> > controlling systems
> >
> > Regarding to the app, management app, end user app here, I want to add
> > something related to the history of this work. At the very beginning,
> > when this work is call APONF before Toronto IETF meeting, the end user
> > app is in the scope. However, there are mainly three reasons that we
> > remove this point:
> >
> > 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,
> >
> >
> >
> > 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.
> >
> > and shares the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > at any level of granularity. Such a graph may describe, for example, a
> > physical topology, a service topology or the relationships between
> > constraints generated by Network Service Systems. They are then mapped
> > from the network graph instance into specific network management
> > policies toward network components.
> >
> >
> >
> >
> >
> > 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:
> >
> >
> >
> > controlling system". What are those? I don't see them in your figure.
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: Ying Cheng <[email-masked]>
Date: Fri, 26 Sep 2014 12:44:38 +0800

Hi all,
 
I attended the e-meeting last night and learned a lot. Thank you for your efforts. The latest charter is now clearer and fine from my side. Later I plan to update the DDC use case accordingly.
 
Some quick comments:

Here do you mean those working group didn’t do your (2). If no, I guess you should use “neither” instead. 
 
In addition, given that there were some discussions related to end user app and management app. You might want to specify the app in this sentence to eliminate confusion.
 
One more comment, I saw you add the term ”interoperable manner” in several places. Could you please elaborate?

BR,
Ying

2014-09-26 

Ying CHENG  程莹
China Unicom Network Technology Research Institute 中国联通网络技术研究院
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

发件人： Tina TSOU 
发送时间： 2014-09-26  08:53:47 
收件人： Benoit Claise 
抄送： [email-masked] 
主题： [Supa] Draft charter v1.12//RE: Area hand-off, and some friendlyadvice ... 
 
Dear Benoit et al,

 

 
 
Deliverables:
=============
 
Milestones:
===========

Thank you,
Tina

Hi Benoit,

Regards,
Will
 
Cc: Zhen Cao; [email-masked]
 
Hi Benoit,

Cc: Zhen Cao; [email-masked]
 
Hi Georgios,
Hi Benoit,

 

 
 
[Will]: First of all, IMOH, the figures from Benoit and Georgios are not incompatible. From the perspective of controller, they are different latitudes of northband. The application and enhanced OSS in Georgios figure can be put together into an larger application* layer of Benoit’s figure. The network graph is proposed to provide network-wide configuration containing the key information for service instances. One example is, for the DDC use case, the network graph contains the key information such as the key node information of the path and the key requirement of traffic steering. 

 

See in-line
Dear all,

------

 

 
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.

 

 

 
Best regards,
Georgios

Regards, Benoit

如果您错误接收了该邮件，请通过电子邮件立即通知我们。[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] if you want to unsubscribe from this mail. We will immediately remove your information from our sending catalogue.

---

From: Georgios Karagiannis <[email-masked]>
Date: Fri, 26 Sep 2014 05:02:02 +0000

Hi Ying,

Please see in line.

> From: Georgios Karagiannis
> Sent: Friday, September 26, 2014 5:52 AM
> To: Georgios Karagiannis
> Subject: RE: [Supa] Draft charter v1.12//RE: Area hand-off, and some
> friendlyadvice ...
> 
> From: Supa [mailto:[email-masked]] On Behalf Of Ying Cheng
> Sent: Friday, September 26, 2014 5:45 AM
> To: supa
> Cc: Benoit Claise; Tina TSOU
> Subject: Re: [Supa] Draft charter v1.12//RE: Area hand-off, and some
> friendlyadvice ...
> 
> Hi all,
> 
> I attended the e-meeting last night and learned a lot. Thank you for your
> efforts. The latest charter is now clearer and fine from my side. Later I plan
> to update the DDC use case accordingly.
> 
> Some quick comments:
> 
> 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 (1) at offering truly generic
> topology models for the standard northbound interface, and (2) that an
> application can communicate with network boxes, such as network controllers,
> and NEs, developed by different vendors.
> 
[>] 

Georgios: We mean that those working groups did not do (1) and (2).
Do we need to change the wording?

> 
> In addition, given that there were some discussions related to end user app
> and management app. You might want to specify the app in this sentence to
> eliminate confusion.
[>] 

Georgios: "Applications" represent an entity that generates and maintains network services and is administrated by a communication service provider.

> places. Could you please elaborate?
[>] 

Georgios: the interoperable manner relates to: requirement that applications should be able to communicate with network boxes, such as network controllers, and NEs, developed by different vendors.

Best regards,
Georgios

> 
> BR,
> Ying
> 
> 2014-09-26
> ________________________________________
> Ying CHENG  程莹
> ________________________________________
> 发件人： Tina TSOU
> Programmatic ways to configure networks, often called software-defined, are
> considered by many network operators in order to shift the balance in their
> favor.
> 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.
> Several organizations outside of the IETF have defined various schemes for the
> configuration of network devices and specific network controllers, but none of
> them offer a vendor-neutral standardized way for applications and network
> services to transmit their needs to network 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. In particular, SUPA will focus on
> service specific models that allow applications to request certain network
> services to be created/deleted/modified. 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.
> communication network. The terms "UNIFIED" and "SHARED" used in the SUPA
> abbreviation, relate to the way of how the service policy model is generated,
> since it groups, unifies and shares the similar requirements imposed by a bulk
> of applications. SUPA will provide guidelines for mechanisms that can
> dynamically and on an interoperable manner, AUTOMATICALLY map services and
> policies defined on an abstract topology graph down to more detailed network
> graphs and specific network management and controlling policies.
> 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 (1) at offering truly generic
> topology models for the standard northbound interface, and (2) that an
> application can communicate with network boxes, such as network controllers,
> and NEs, developed by different vendors.
> and links at any level of granularity. Such a network graph describes (1)
> topologies at different levels of abstraction, (2) the relationships between
> the abstraction levels and (3) applied service based policy, which are actions
> and constraints applied on these topologies. SUPA may also define any mappings
> to any other network topology data models defined within the IETF.
> applications to request network services to be created/deleted/modified. This
> can be realized by:
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanism and
> authorization mechanisms to achieve protection and isolation
> 
> Deliverables:
> =============
> o) Produce standards-track RFCs 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 informational RFC that provides the guidelines for mechanisms
> that can dynamically and on interoperable manner, automatically map services
> o) Produce an informational RFC that provides the guidelines on using NETCONF
> (or RESTCONF) authentication and authorization mechanisms to achieve security
> protection and isolation' as an Informational RFC.
> 
> Milestones:
> ===========
> model I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr
>                       |   <--- network service | YANG models  /NETCONF
> interface                |
>              |   controller                       |               <---
>   mapping network services to topology
>                  |       |        |                    <--- device/feature
> specific YANG models / NETCONF interface
>              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.
> 
> 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.
> 
> [Will]: First of all, IMOH, the figures from Benoit and Georgios are not
> incompatible. From the perspective of controller, they are different latitudes
> of northband. The application and enhanced OSS in Georgios figure can be put
> together into an larger application* layer of Benoit’s figure. The network
> graph is proposed to provide network-wide configuration containing the key
> information for service instances. One example is, for the DDC use case, the
> network graph contains the key information such as the key node information of
> the path and the key requirement of traffic steering.
> 
> something related to the history of this work. At the very beginning, when
> this work is call APONF before Toronto IETF meeting, the end user app is in
> the scope. However, there are mainly three reasons that we remove this point:
> 1.      The confliction with AECON, we discussed with proponents of AECON and
> to avoid the conflict as at that time they were proposing the interface from
> end user app to network devices. Later in the IESG meeting in Toronto, we
> successfully clarified the differences and got the suggestion to focus on
> management app.
> 2.      Lars Eggert showed his concerning about the interface between end user
> app and network devices may lead to security issue.  Kostas Pentikousis also
> mentioned this to me.
> 
> However, these are old stories. During the Toronto BoF, someone also suggested
> us re-put the end user app into cope. A large app layer containing both end
> user app and management app may replace the first two layers in the old 4
> layers figure. Here, my question is, are you in favor of adding end user app
> into SUPA scope or not?
> 
> 
> 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
> 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.
> 
> 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.
> [Will] To modeling service requirement and create service instances, APP needs
> a view of topology to form network configuration according to the key
> information of devices topology. This configuration is eventually mapped to
> the selected network devices according to topology provided by SUPA.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
> 
> Regards, Benoit
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到hqs-
> [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。
> If you have received this email in error please notify us immediately by e-
> mail. Please reply to [email-masked] if you want to unsubscribe from
> this mail. We will immediately remove your information from our sending
> catalogue.

---

From: Ying Cheng <[email-masked]>
Date: Fri, 26 Sep 2014 14:22:18 +0800

Hi Georgios,

Thanks for your quick explaination. It is clear for me.

BR,
Ying

2014-09-26 

Ying CHENG  程莹

发件人： Georgios Karagiannis 
发送时间： 2014-09-26  13:02:17 
收件人： Ying Cheng(联通集团联通网络技术研究院) 
抄送： Benoit Claise; Tina TSOU; supa 
主题： RE: [Supa] Draft charter v1.12//RE: Area hand-off, and somefriendlyadvice ... 
 
Hi Ying,
[>]
[>]
[>]