Re: [Nfvrg] NFVRG meeting at IETF 91 -- call for presentations and drafts

이승익 <seungiklee@etri.re.kr> Tue, 28 October 2014 02:50 UTC

Return-Path: <seungiklee@etri.re.kr>
X-Original-To: nfvrg@ietfa.amsl.com
Delivered-To: nfvrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727521A1B73 for <nfvrg@ietfa.amsl.com>; Mon, 27 Oct 2014 19:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.61
X-Spam-Level:
X-Spam-Status: No, score=-101.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
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 E50-dj3cNDaa for <nfvrg@ietfa.amsl.com>; Mon, 27 Oct 2014 19:50:06 -0700 (PDT)
Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6661A1B74 for <Nfvrg@irtf.org>; Mon, 27 Oct 2014 19:50:05 -0700 (PDT)
Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 28 Oct 2014 11:50:04 +0900
Received: from SMTP1.etri.info ([169.254.1.130]) by SMTP3.etri.info ([10.2.6.32]) with mapi id 14.01.0355.002; Tue, 28 Oct 2014 11:50:00 +0900
From: 이승익 <seungiklee@etri.re.kr>
To: ramki Krishnan <ramk@Brocade.com>
Thread-Topic: [Nfvrg] NFVRG meeting at IETF 91 -- call for presentations and drafts
Thread-Index: Ac/c2lIpyWrD0wXcQomEgfpfcMvPJQArDmowAAAZs/AFNJoy0A==
Date: Tue, 28 Oct 2014 02:49:59 +0000
Message-ID: <2EDFB4D974E4AC45B641E2B5F734E6C21D6972F5@SMTP1.etri.info>
References: <C7634EB63EFD984A978DFB46EA5174F2C1523BA8AD@HQ1-EXCH01.corp.brocade.com>
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2C1523BA8AD@HQ1-EXCH01.corp.brocade.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.254.170.46]
Content-Type: multipart/alternative; boundary="_000_2EDFB4D974E4AC45B641E2B5F734E6C21D6972F5SMTP1etriinfo_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nfvrg/bp8N3qq0gnoJ8gOeXZpj_MlmoII
Cc: "Nfvrg@irtf.org" <Nfvrg@irtf.org>, "DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com)" <diego.r.lopez@telefonica.com>, "'dilikris@in.ibm.com'" <dilikris@in.ibm.com>
Subject: Re: [Nfvrg] NFVRG meeting at IETF 91 -- call for presentations and drafts
X-BeenThere: nfvrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Function Virtualization Research Group \(NFVRG\) discussion list" <nfvrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/nfvrg>, <mailto:nfvrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/nfvrg/>
List-Post: <mailto:nfvrg@irtf.org>
List-Help: <mailto:nfvrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/nfvrg>, <mailto:nfvrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 02:50:08 -0000

Ramki,


Can I have a 5min slot for an update of service chain adaptation with http://www.ietf.org/internet-drafts/draft-lee-nfvrg-resource-management-service-chain-00.txt ?
And I could also give its applicability to SFC.

Regards,
Seung-Ik.

From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of ramki Krishnan
Sent: Wednesday, October 01, 2014 11:52 PM
To: Nfvrg@irtf.org
Cc: DIEGO LOPEZ GARCIA (diego.r.lopez@telefonica.com); 'dilikris@in.ibm.com'
Subject: [Nfvrg] NFVRG meeting at IETF 91 -- call for presentations and drafts

Dear All,

The proposed Network Functions Virtualization Research Group (NFVRG) will hold its next meeting in conjunction with IETF 91,  November 9-14 in Honolulu, Hawaii. The NFVRG Program Committee is now
seeking proposals for presentations and drafts for the IETF 91 agenda, details are below.

For presentations please contact Ram (Ramki) Krishnan (Brocade - ​ramk@brocade.com<mailto:ramk@brocade.com>), Dilip Krishnaswamy (IBM Research - ​dilikris@in.ibm.com<mailto:dilikris@in.ibm.com>), Diego Lopez (Telefonica - ​diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>)
For drafts, please post them to the NFVRG mailing list ​(nfvrg@irtf.org<mailto:nfvrg@irtf.org>). An exemplary NFVRG draft is -- http://tools.ietf.org/html/draft-krishnan-nfvrg-open-nfv-virality-00.
Call for Presentations -- Areas of Interest (from http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg)
• Network and service function chaining: architecture and implementation (e.g. automation of service chain building)
• Autonomous service orchestration and optimization
• New operational aspects of network and service virtualization, as well as new operational models required by virtualization
• Infrastructure and service function description and programming (languages, APIs, frameworks for combined processing, network and storage programming)
• Virtualized network economics and business modeling
• Security, trust and service verification
• Real-time big data analytics and data-centric management of virtualized infrastructure
• New application domains enabled by virtualized infrastructure and services
• System wide optimization of compute, storage, network and energy efficiency
• Explore infrastructure and service abstractions enabled by virtualization
• Autonomic and real-time orchestration enabled by network function virtualization
Call for Drafts -- Based on Near Term Charter (from http://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg)
For each of the near term charter areas mentioned below, the goal is to explore system architecture and optimization with open interfaces across components and explore research through simulations and/or real-world implementations.
Policy based Resource Management: NFV DCs are often constrained in compute and storage capacity. Since practically all NFV DCs are foreseen to be distributed, inter-DC network capacity is also a constraint. Additionally, energy is also a constraint, both as a general concern for NFV operators, and for specific-purpose NFV DCs such as those in mobile base stations, enterprise branch offices that often have power limitations. Hence, optimized resource management and workload distribution based on policy is a relevant area to focus on.
Analytics for Visibility and Orchestration: Network functions should be supportable on general purpose commodity hardware. Real-time analytics providing insight into various components such as compute (e.g. dynamic CPU utilization), storage (e.g. dynamic capacity usage), network (e.g. dynamic bandwidth utilization), energy (e.g. dynamic power consumption) is key to not only providing visibility into the NFV infrastructure but also optimizing resource usage for the purposes of orchestration. This is a relevant area to focus on.
Virtual Network Function (VNF) Performance Modelling to facilitate transition to NFV: While migrating from hardware network appliances, which are typically custom and monolithic, to virtualized software appliances running on commodity hardware a challenge which is often faced is to come up with an equivalence model especially in terms of performance. This is a relevant area to focus on.
Security and Service Verification: NFV configuration is expected to be dynamic especially in the edge NFV DCs where capacity is limited; a very good example is handling a viral event such as mobile gaming application. While autonomic networking techniques could be used to automate the configuration process including modular updates, it is important to take into account that incomplete and/or inconsistent configuration may lead to security issues. Additionally, events such as distributed denial of service (DDoS) attacks could be an additional source of compromise with additional implications due to the dependency of NFV on a distributed infrastructure. Finally, elasticity of VNFs entails dynamic scale up/down/out with awareness of the resiliency considerations, completely different with the approach of monolithic implementations. Security issues and relevant solutions related to the elastic nature of VNFs is a potential area to consider.
Thanks,
Ramki (on behalf of the co-chairs)