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

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sat, 14 June 2014 14:11 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B1F1B28F1 for <openv6@ietfa.amsl.com>; Sat, 14 Jun 2014 07:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUQsN8_V_OZ2 for <openv6@ietfa.amsl.com>; Sat, 14 Jun 2014 07:11:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE50B1B2853 for <Openv6@ietf.org>; Sat, 14 Jun 2014 07:11:33 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFK25341; Sat, 14 Jun 2014 14:11:31 +0000 (GMT)
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 14 Jun 2014 15:11:30 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.210]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sat, 14 Jun 2014 22:11:23 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>, "jsaldana@unizar.es" <jsaldana@unizar.es>, "Openv6@ietf.org" <Openv6@ietf.org>
Thread-Topic: [Openv6] Is there a draft charter for APONF?
Thread-Index: Ac+D9qNFruvdoEliTFauT0nZdN8okwAEVOrrAB1I+KAA11qzdg==
Date: Sat, 14 Jun 2014 14:11:23 +0000
Message-ID: <6344BC5E-9EF0-45CD-9664-91CD60193E18@huawei.com>
References: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> <FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA59@EXMBX23.ad.utwente.nl>, <C0E0A32284495243BDE0AC8A066631A8183369BC@szxeml557-mbs.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A8183369BC@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6344BC5E9EF045CD966491CD60193E18huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/Or3XYIffq6Q-FRvM0XlPUge2rMo
Subject: Re: [Openv6] Is there a draft charter for APONF?
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jun 2014 14:11:42 -0000

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" <Tina.Tsou.Zouting@huawei.com<mailto:Tina.Tsou.Zouting@huawei.com>> 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:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl>
Sent: Tuesday, June 10, 2014 1:28 AM
To: jsaldana@unizar.es<mailto:jsaldana@unizar.es>; Openv6@ietf.org<mailto:Openv6@ietf.org>
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 [openv6-bounces@ietf.org<mailto:openv6-bounces@ietf.org>] namens Jose Saldana [jsaldana@unizar.es<mailto:jsaldana@unizar.es>]
Verzonden: maandag 9 juni 2014 17:26
Aan: Openv6@ietf.org<mailto:Openv6@ietf.org>
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