Re: [Nfvrg] We need your feedback on the NFVRG proposed charter

Ramki Krishnan <ramk@Brocade.com> Sat, 13 December 2014 05:05 UTC

Return-Path: <ramk@Brocade.com>
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 46DEA1A9248 for <nfvrg@ietfa.amsl.com>; Fri, 12 Dec 2014 21:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 i8kWY6yqFido for <nfvrg@ietfa.amsl.com>; Fri, 12 Dec 2014 21:05:52 -0800 (PST)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C981E1A9241 for <nfvrg@irtf.org>; Fri, 12 Dec 2014 21:05:51 -0800 (PST)
Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id sBD55cxw022722; Fri, 12 Dec 2014 21:05:38 -0800
Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1r88t3gnpq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 12 Dec 2014 21:05:37 -0800
Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Dec 2014 21:05:36 -0800
Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 12 Dec 2014 22:05:35 -0700
Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 12 Dec 2014 22:05:34 -0700
Received: from BRMWP-EXMB12.corp.brocade.com ([fe80::c813:1b29:645:33bf]) by BRMWP-EXMB12.corp.brocade.com ([fe80::c813:1b29:645:33bf%26]) with mapi id 15.00.0995.031; Fri, 12 Dec 2014 22:05:34 -0700
From: Ramki Krishnan <ramk@Brocade.com>
To: XILOURIS George <xilouris@iit.demokritos.gr>, "이승익 (seungiklee@etri.re.kr)" <seungiklee@etri.re.kr>
Thread-Topic: [Nfvrg] We need your feedback on the NFVRG proposed charter
Thread-Index: AQHQE4P7QM1zLEih6kibvYbooFL/SZyISHCAgAAG8WCAAUDXgIADISTQ
Date: Sat, 13 Dec 2014 05:05:33 +0000
Message-ID: <26e4f193e2d344ac94058a4bba3e8c0e@BRMWP-EXMB12.corp.brocade.com>
References: <f91cd0b162204da1969b9f24a515ce41@BRMWP-EXMB11.corp.brocade.com> <1B7A8013-EFCF-44CD-B818-C1A5DA67E4F2@telefonica.com> <4A95BA014132FF49AE685FAB4B9F17F645E7A53D@dfweml701-chm> <6da7a1d2a9c84db995466eeaca9430c1@BRMWP-EXMB11.corp.brocade.com> <31069E18-CC1F-48B7-918E-27BBC503CCDD@iit.demokritos.gr>
In-Reply-To: <31069E18-CC1F-48B7-918E-27BBC503CCDD@iit.demokritos.gr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.180.50]
Content-Type: multipart/alternative; boundary="_000_26e4f193e2d344ac94058a4bba3e8c0eBRMWPEXMB12corpbrocadec_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-13_02:2014-12-13,2014-12-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412130049
Archived-At: http://mailarchive.ietf.org/arch/msg/nfvrg/rAPmmcCGcOZIxh_Z6hdVA5lsc70
Cc: "nfvrg@irtf.org" <nfvrg@irtf.org>, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [Nfvrg] We need your feedback on the NFVRG proposed charter
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: Sat, 13 Dec 2014 05:05:57 -0000

Dear George,

Great discussion points, please find inline.

Thanks,
Ramki

From: XILOURIS George [mailto:xilouris@iit.demokritos.gr]
Sent: Wednesday, December 10, 2014 9:45 AM
To: Ramki Krishnan
Cc: Linda Dunbar; DIEGO LOPEZ GARCIA; nfvrg@irtf.org
Subject: Re: [Nfvrg] We need your feedback on the NFVRG proposed charter

Dear Ramki,

>>In to my mind the term SFC does make sense at the Orchestration level where the actual Service context is known by the Orchestrator. In the controller level however SFC seems to be more specific to the methods to establish the chaining at the network and service function level. What essentially is done at the controller level is to steer traffic according to the policies established by the SFC @ Orchestration. The exact context or purpose or essentially the Service that is realised by the applied traffic redirections/tunneling etc might not be known to the controller.

Yes mostly. What we have to keep in mind is that there could be policies in the network controller level and orchestration level. The network controller level policies would be of network scope. For example, a controller level policy could say connect VNFs A,B and C; this policy could be realized by multiple possible overlay/transport technologies. An orchestration level policy is applicable to multiple sub-systems such as compute, network, storage etc.. For example, an orchestration policy could specify that a customer X should be given gold treatment for a given ordered service chain comprising of a set of VNFs. This could map to different policies (thus resultant configurations) in different sub-systems, for example specific server types, HW acceleration etc..

You may have seen a related draft and presentation on the SFC topic “Resource Management for Dynamic Service Chain Adaption” in IETF 91 from Lee, also copying him.
Presentation Link: http://www.ietf.org/proceedings/91/slides/slides-91-nfvrg-0.pptx
Draft Link: https://datatracker.ietf.org/doc/draft-lee-nfvrg-resource-managementservice-chain/

With regard to policy, we have a draft -- https://datatracker.ietf.org/doc/draft-norival-nfvrg-nfv-policy-arch/?include_text=1.

It would be great to continue discussions on these topics.

>>A good idea would be to use an  explicit term to differentiate among SFC at different layers. It seems that our boundaries with SFC WG are the from the 5th point (Manageability) of its charter description and beyond.

Completely agree.

Then again chances are that I have  gaps in my view. :-)

Best Regards
George

On Dec 9, 2014, at 11:37 PM, Ramki Krishnan <ramk@Brocade.com<mailto:ramk@Brocade.com>> wrote:

Hi Linda,

Good question. NFVRG would be examining service chaining at an orchestration level whereas the SFC work is at the controller level.

Thanks,
Ramki

From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Linda Dunbar
Sent: Tuesday, December 09, 2014 2:11 PM
To: DIEGO LOPEZ GARCIA; nfvrg@irtf.org<mailto:nfvrg@irtf.org>
Subject: Re: [Nfvrg] We need your feedback on the NFVRG proposed charter

Diego,

It is a good charter proposal. I support it.

Your second bullet is about Service Chaining. Is it something that is covered by SFC WG or beyond what SFC is currently chartered to do?

• Network and service function chaining: architecture and implementation (e.g. automation of service chain building)


Thanks, Linda

From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Tuesday, December 09, 2014 1:44 AM
To: nfvrg@irtf.org<mailto:nfvrg@irtf.org>
Subject: [Nfvrg] We need your feedback on the NFVRG proposed charter

Hi,

Just for you to know, NFVRG is still under the status of "proposed RG" in the IRTF. To move into a stable RG status we need to agree in a charter, and to do so the IRTF requires us to collect explicit feedback from the community.

So please review the text included below (predominantly what we discussed in the meetings so far and in the NFVRG wiki page https://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg with minor edits) and make your comments and/or express your explicit support (the usual "+1" would be enough)

Be goode,

8<--

Network Function Virtualization Research Group (NFVRG)

Background
Network Function Virtualization is a key emerging area for network operators, hardware and software vendors, cloud service providers, and in general network practitioners and researchers. This area requires exploring new directions and working collaboratively on how to create network services that utilize a virtualized infrastructure. Network functions that are traditionally implemented in dedicated hardware appliances will need to be decomposed and executed in software elements running on cloud-based infrastructures. One essential goal of this new approach is to reduce capital and operating expenditures for future deployments for networks and associated services. Another important goal is for the network operators to be able to offer value added cloud services to their customers. Finally, new business models will open for the provision of network services.

The technologies enabling the virtualization of network functions are currently in an early stage, and they need researchers to develop new architectures, systems, and software, and to explore tradeoffs and possibilities for leveraging virtualized infrastructure to provide support for network functions. The Network Functions Virtualization Research Group (NFVRG) will bring together researchers and grow the community around the world in both academia and industry to explore this new research area. Beyond the direct activity through the IRTF collaboration tools it will organize research group meetings and workshops at premier conferences (such as IEEE ICC, IEEE Globecom) and inviting special issues in well-known journals.

The NFVRG will focus on research problems associated with NFV-related topics and on bringing a research community together that can jointly address them, concentrating on problems that relate not just to networking but also to computing and storage constraints in such environments. It is also hoped that the outcome of the research will benefit standardization efforts that can get spawned via IRTF & IETF BoF meetings and/or provide useful input to other related standards efforts in ETSI or other standards bodies.

Areas of Interest
• New network architectures based on virtualized network functions
• 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)
• Coexistence with non-virtualized infrastructure and services
• 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
The group will report progress through its wiki and presentations at IETF and IRTF meetings. Relevant information and research developed by the research group will be submitted for publication as Experimental or Informational RFCs.

Near Term Work Items
The group shall focus on a concrete list of near-term work items. For each of the items mentioned below, the goal is to explore system architecture, optimization, and open interfaces across components, through simulations and/or real-world implementations.

Policy based Resource Management:
NFV Point of Presence (PoP) will be likely constrained in compute and storage capacity. Since practically all NFV PoPs are foreseen to be distributed, inter-datacenter network capacity is also a constraint. Additionally, energy is also a constraint, both as a general concern for NFV operators, and in particular for specific-purpose NFV PoPs such as those in mobile base stations. This work item will focus on optimized resource management and workload distribution based on policy.

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) are key to not only providing visibility into the NFV infrastructure but also optimizing resource usage for the purposes of orchestration. This work item will contemplate techniques for the applicability of real-time analytics.

Virtual Network Function (VNF) Performance Modeling to facilitate transition to NFV:
While migrating from hardware network appliances, which are typically custom and monolithic, to virtualized software implementations running on commodity hardware a challenge which is often faced is to come up with an equivalence model especially in terms of performance. The work item will consider this modeling.

Security and Service Verification:
NFV configuration is expected to be dynamic especially in the edge NFV PoP 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 are the objectives of this work item.

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
Nfvrg mailing list
Nfvrg@irtf.org<mailto:Nfvrg@irtf.org>
https://www.irtf.org/mailman/listinfo/nfvrg