Re: [Openv6] Is there a draft charter for APONF?

[Tina TSOU <[e-mail]>]

Dear all,

Based on everybody's feedback, here comes the 3rd version of the charter.

Hope it is more precise and concrete for you to comment on.

------------------------------------
APONF (Application-based Policy for Network Functions) charter

Target Area: Operations and Management Area

Description of Working Group:

Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than  manipulating individual devices. An abstract view of a network infrastructure can be realized using  a network configuration model, that provides a declarative configuration and a network topology model that describes a multi-layer network. Network management applications are Operational Support System (OSS) like applications that help a communication service provider to monitor, control, analyze and manage a communication network.
In this context, network management applications can be used to provide the required configuration and application programming interfaces to such service developers. Subsequently, a network management application can use the application based demands and possibly update its associated network configuration and/or network topology model. Examples of network management applications that can modify the network configuration and/or network topology models are for example, virtual network function services, Distributed Data Center Application, IPv6 transitions, streaming and IoT applications, need to change the network infrastructure configuration.
The updated network configuration and network topology model needs to be communicated to e.g., the network management system, the routing controlling system or other controlling systems, to map the network configuration and network topology models into specific device level configuration models.

Currently, there are no IETF standard mechanisms or modeling languages that can directly be applied to model the network configuration nor the network topology. IETF has however, created the IETF SFC WG to document a new approach to service delivery and operation, where one of its goals is to realize an abstract view of a network by using a service graph denoted as the Service Function Path (SFP). This will enable the development of suitable models for network configuration and network topology.
Furthermore, there are currently no IETF solutions that can be used to provide the necessary configuration interfaces to service developers to program the abstract view of a network infrastructure. Currently, the Application Enabled Collaborative Network (AECON) activity can provide these necessary solutions.

Moreover, there are no IETF solutions that can directly be used to (1) enable the streaming transfer of bulk-variable/data of network configuration and network topology models between network management application systems and e.g., the network management system, the routing controlling system or other controlling systems, and (2) map the network configuration and network topology models into specific device level configuration models. The APONF activity can provide a solution to this challenge.

The main goal of APONF is to:
o) enable the streaming transfer of bulk-variable/data of the up to date SFP based network configuration and network topology models between network management application systems and e.g., the network management system, the routing controlling system or other controlling systems, by using and extending the IETF Next Steps in Signaling Protocol (NSIS).
o) map the SFP based network configuration and network topology models into specific device level configuration models.

The APONF requirements/objectives are:

o) monitor and verify the freshness of the SFP based network configuration and network topology models

o) extend the IETF NSIS protocol to securely and efficiently distribute the SFP based network configuration and network topology models between network management applications (e.g., OSS applications) and e.g., the network management system, the routing controlling system or other controlling systems

o) use application based demands generated by network management applications to map the SFP based network configuration and network topology models into specific device level configuration models. Such application based demands are:

a) Encapsulating, de-encapsulating packets associated with a flow into a tunnel (for example, VPN service, IPv6 transition service need to manage the network function to do that):

b) blocking, or dropping packets associated with a flow in (the edge of) the network element when the network security service is aware of the attack (for example, SAVI service, Anti-DoS service need to manage the network function to do that).

c) configure and dynamically reconfigure data centers to the steer and reroute traffic associated with a specific flow

d) configure and dynamically reconfigure data centers to  change priorities of different types of traffic associated with a specific flow

e) Logging the traffic associated with a flow for network security service, optimization of the traffic in network for IETF ALTO service

f) other actions defined by the administrator

o) specify the Authentication Authorization and Accounting (AAA) method

Work items related to APONF include:
o) specify the problem statement and use cases

o) specify the APONF architecture

o) specify extensions to the IETF NSIS protocol to distribute the SFP based network configuration and network topology models between network management applications (e.g., OSS applications) and e.g., the network management system, the routing controlling system or other controlling systems. The IETF Next Steps in Signaling (NSIS) protocol may be extended in two ways to support this interface:
a) Extend NSIS GIST to be used for off-path support

b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar to the NAT/Firewall NSLP and QoS NSLP that can be applied and support the APONF use cases.

o) map the SFP based network configuration and network topology models into specific device level configuration models

o) specify the AAA method.

Milestones:

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

I-D 'APONF Architecture' as an Informational RFC.

I-D 'Mapping SFP based models into specific device level configuration models' as an Informational RFC.

I-D 'APONF based NSIS Protocol Specification' Standards Track RFC.
--------------------------------------


Thank you,
Tina

From: Openv6 [mailto:[e-mail]] On Behalf Of Tina TSOU
Sent: Saturday, June 14, 2014 10:11 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Openv6] Is there a draft charter for APONF?

Dear all,

Below is 2nd version of the charter based on all the feedback, many things are removed.

Comments are very welcome.

----
APONF (Application-based Policy for Network Functions) charter

Description of Working Group:

Currently, there are network management applications that have specific demands on a communication network. For example, some specialized applications, like virtual network function services and Distributed Data Center Application, may need to *dynamically manage* the network infrastructure, and other specialized applications, like streaming applications and Internet of Things (IoT) applications, may require to configure the network according to their demands. If possible, a network management application may require from the communication network to apply the following different network management capabilities, such as:
*             dynamically (re)configure a network entity
*             accelerate the service deployment
*             getting better network services from transport network
*             providing better user experience

The network management application's demands on a communication network are different, but there are several demands that may be similar, such as different Web Surfing/Browsing applications, IoT applications, virtual network function services, Distributed Data Center Application, which can be grouped/classified together. The classified network management application demands on a communication network can be presented and modeled as classified network management application-based policies. A set of network management application-based policy models may be needed for auto-mapping of network management application's demands to existing network management policies. This will allow network management applications to use the network capabilities in a more accurate and efficient way.

The definition of these network management policies is out of the APONF scope.

Examples of such network management policies that are considered by APONF are the following:

*             Manage dynamically network semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function Virtualization configuration) BOF activity)
*             Orchestrate dynamically virtualized functions (supported by e.g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF activity, Abstraction and Control of Transport Networks (ACTN) BOF activity)
*             Log the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)
*             Set the traffic, e.g., encapsulation/decapsulation (supported for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)

These network management application-based policy models can meet the network management application's demands on the communication network and map these demands to network management policies that can be understood by the communication network.

The main goal of APONF is to specify the network management application-based policy protocol(s), mechanisms and models required  by network management applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management policies.

The users of the APONF are network management applications requests that have specific demands on a communication network.

Work items related to APONF include:
*             specify the APONF groups/classes of application policies and models
*             provide mechanisms that can accurately map and store the APONF groups/classes of application policies and models into existing network management policies.
*             specify the protocol and the required mechanisms that are able  to support the communication between the network management applications and the ABPD entity that maintains the groups/classes of application policies and models.
*             provide the means to use existing network management protocols and mechanisms to enforce the  network management application policies (via the associated network management policies) into network entities. Such protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, MPLS.
*             provide authentication and authorization mechanisms to support the communication between the Network Management Application and the ABPD entity.
*             provide privacy support for the end users running the applications that make use of the APONF protocol and mechanisms.

Initially, the APONF work will focus on the follow aspects:
*             high-level architecture
*             Solution requirements
*             a set of application based policy models for different classes of applications
*             a set of use cases
*             analysis of existing protocols that can be reused in the architecture

Milestones:
*             November 2014 Submit I-D 'Use cases' to the IESG for consideration as an Informational RFC.
*             February 2015 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC.
*             March 2015 Submit I-D 'High level Architecture' to the IESG for consideration as an Informational RFC.-
*             July 2015 Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.-
*             Jul y2015 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group
-----



Thank you,
Tina

On Jun 10, 2014, at 4:00 PM, "Tina TSOU" <[e-mail]<mailto:[e-mail]>> wrote:
Dear all,

Here is the first cut of a draft charter for APONF.

APONF (Application-based Policy for Network Functions) charter

Description of Working Group:

Currently, there are transport applications that have specific demands on a communication network. For example, some specialized applications, like virtual network function services, may need to *dynamically manage* the network infrastructure, and other specialized applications, like streaming applications and Internet of Things (IoT) applications, may require from the network to treat their traffic according to their demands. If possible, a specialized application may require from the communication network to apply the following different network management and/or traffic  capabilities, such as:
*             dynamically (re)configure a network entity
*             accelerate the service deployment
*             getting better network services from transport network
*             providing better user experience

The application's demands on a communication network are different, but there are several specialized application demands that may be similar, such as different IoT applications, virtual network function services, which can be grouped/classified together. The classified application demands on a communication network can be presented and modeled as classified application-based policies. A set of application-based policy models may be needed for auto-mapping of application's demands to existing network management and/or traffic policies. This will allow applications to use the network capabilities in a more accurate and efficient way.

The definition of these network management and traffic policies is out of the APONF scope.

Examples of such network management and traffic policies that are considered by APONF are the following:

*             Manage dynamically network semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function Virtualization configuration) BOF activity)
*             Orchestrate dynamically virtualized functions (supported by e.g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF activity, Abstraction and Control of Transport Networks (ACTN) BOF activity)
*             Permit/Block/Redirect the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)
*             Log the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)
*             Copy the traffic, e.g., multicast (supported by e.g.,I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity
*             Set the traffic, e.g., encapsulation/decapsulation (supported for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)
*             Mark the traffic (supported for/by e.g., Intserv, Diffserv, PCN, MPLS)

These application-based policy models can meet the specialized application's demands on the communication network and map these demands to network management and traffic policies that can be understood by the communication network.

The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required  by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies.

The users of the APONF may be the network management applications, or (BOF) TAPS (Transport Services) requests that have specific demands on a communication network.

Work items related to APONF include:
*             specify the APONF groups/classes of application policies and models
*             provide mechanisms that can accurately map and store the APONF groups/classes of application policies and models into existing network management and traffic policies.
*             specify the protocol and the required mechanisms that are able  to support the communication between the transport applications and the ABPD entity that maintains the groups/classes of application policies and models.
*             provide the means to use existing network management and/or traffic conditioning protocols and mechanisms to enforce the  application policies (via the associated network management and traffic policies) into network entities. Such protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, MPLS.
*             provide authentication and authorization mechanisms to support the communication between the Transport Application and the ABPD entity.
*             provide privacy support for the end users running the applications that make use of the APONF protocol and mechanisms.

Initially, the APONF work will focus on the follow aspects:
*             high-level architecture
*             Solution requirements
*             a set of application based policy models for different classes of applications
*             a set of use cases
*             analysis of existing protocols that can be reused in the architecture

Milestones:
*             November 2014 Submit I-D 'Use cases' to the IESG for consideration as an Informational RFC.
*             February 2015 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC.
*             March 2015 Submit I-D 'High level Architecture' to the IESG for consideration as an Informational RFC.-
*             July 2015 Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.-
*             Jul y2015 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group


Thank you,
Tina

From: Openv6 [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, June 10, 2014 1:28 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Openv6] Is there a draft charter for APONF?

Hi Jose,


Thanks for the comments!
Yes we are planning to create a APONF BOF charter soon!

Best regards,
Georgios

________________________________
Van: Openv6 [[e-mail]<mailto:[e-mail]>] namens Jose Saldana [[e-mail]<mailto:[e-mail]>]
Verzonden: maandag 9 juni 2014 17:26
Aan: [e-mail]<mailto:[e-mail]>
Onderwerp: [Openv6] Is there a draft charter for APONF?
Hi,

I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki.

Is there a draft charter somewhere? In case not, I would suggest to write a first version and send it to the list. It would be somewhat similar to the BoF summary, but it would also include the goals and milestones, deliverables of the potential WG, interactions with other WGs, etc.

Best regards,

Jose Saldana