Re: [vnfpool] 答复: 答复: Updated VNFPool Charter

[LAC Chidung <[e-mail]>]

Hi Ning,
Thank you for the reply. Some comments/suggestions to your:
* comment Z2:I knew that the « elementary » NFs are part of the job, but 
wanted to suggest to add something in this section to avoid readers to 
perceivethe wrong feeling mentioned in my comment #1
* comment Z7:Thank you for this clarification. I thus understand that 
three types of pools (and not more than three) may exist:
      - (i) no redundancy at all, i.e., all instances of the pool 
participate actively - an upstream load balancing mechanism shares the 
incoming load among these instances;
      - (ii) 1:1 (active-active) redundancy - for example, 5 "images" 
(to avoid the word 'instance') of the VNF, and each of them is redundant 
-> in this case, there are 10 instances running in parallel in the pool;
      - (iii) N+K (active-standby) redundancy where some instances run 
actively, while others are in a dormant state.
* comment Z9:How about this add-on then ? "... achieved by the VNF Pool 
*architecture* utilized/adopted by the VNF ..."
Best,
Chidung

Le 19/06/2014 05:14, Zongning a écrit :
>
> Hi, Chidung,
> Please see my reply enclosed in the attachment. Regarding comment#6, 
> I’d like to explain that we don’t restrict to the case that in a pool, 
> at a given time, there is only one running instance and all others are 
> sleeping. A pool should be flexible to handle more cases, including 
> multiple running instances and multiple standby instances.
> Look forward to your further comments & suggestions.
> -Ning
>
> *发 件人:*LAC Chidung [mailto:[e-mail]]
> *发 送时间:*2014年6月19日0:40
> *收件人:*Zongning
> *抄送:*[e-mail]
> *主题:*Re: [vnfpool] 答复: Updated VNFPool Charter
>
> Hi Ning,
> 1) Is it exact that scaling out/in, one main characteristic of VNFs 
> (compared to PNFs), is not included ?
> 2) Some comments/suggestions are enclosed.
> Best,
> Chidung
>
> Le 12/06/2014 05:38, Zongning a écrit :
>
>     Dear all,
>     Please review the charter text included in the last email. We are
>     hoping that a general consensus on the charter could be achieved
>     on the list, then a stable charter is ready for the VNFPool
>     session in Toronto.
>     Thanks.
>     -Ning
>
>     *发件人:*vnfpool [mailto:[e-mail]] *代 表 *Zongning
>     *发 送时间:*2014年6月12日11:20
>     *收件人:*[e-mail] <mailto:[e-mail]>
>     *主题:*[vnfpool] Updated VNFPool Charter
>
>     Dear all,
>
>     Based on the list discussion since we posted the last version, I
>     have made some (minor) revision of the charter. The main changes are:
>
>     1)State that service state synchronization is out of scope “in
>     this phase”;
>
>     2)Include VNF Pool with both virtualized and non-virtualized
>     network function for further study;
>
>     3)Explicitly state that the reference solution & gap analysis is
>     not limited to RSerPool, but open to any other solutions, although
>     no decision on protocols will be made in this phase;
>
>     4)State that the linkage between SFC and VNF Pool is just like a
>     pool user and a pool – nothing specified (yet);
>
>     5)Update bullet #4 under “Questions that are raised…”, to keep it
>     consistent with the idea that pooling is not visible to the
>     service control entity.
>
>     ==========================================================================
>
>     Network functions such as firewalls, load balancers, and WAN
>     optimizers are conventionally deployed as specialized hardware
>     servers in both network operators' networks and data center
>     networks as the building blocks of the network services. There is
>     a trend to implement such network functions as software instances
>     running on general purpose servers, via a virtualization layer
>     (i.e., hypervisors). These virtualized functions are called
>     Virtualized Network Functions (VNFs), which can be used to build
>     network services.
>
>     The use of VNFs introduces additional challenges to the
>     reliability of the provided network services. A single VNF
>     instance would typically not have built-in reliability mechanisms
>     on its host (i.e., a general purpose server). Instead, there are
>     more factors of risk such as software failure at various levels
>     including hypervisors and virtual machines, hardware failure, and
>     instance migration that can make a VNF instance unreliable.
>
>     In order to achieve higher reliability, a VNF may adopt a pooling
>     mechanism, where a number of VNF instances with the same function
>     can be grouped as a pool to provide the function. We call such a
>     pool a VNF Pool.Conceptually, a Pool Manager is used to manage a
>     VNF Pool, e.g., selects active/standby VNF instances, and
>     potentially interacts with a service control entity. Such a
>     service control entity is an entity that orchestrates a set of
>     network functions to build network services. The major benefit of
>     using VNF Pool is that reliability mechanisms such as redundancy
>     model are achieved by the VNF Pool inside the VNF and thus not
>     visible to the service control entity. A VNF Pool-enabled VNF
>     still appears as a normal VNF when orchestrated by a service
>     control entity.
>
>     Questions that are raised by the addition of a pooling mechanism
>     to VNF include:
>
>     ·How to manage the redundancy model, e.g., select active/standby
>     VNF instances in a VNF Pool?
>
>     ·What pool states need to be maintained to support the pooling
>     mechanism itself, and how are such states maintained?
>
>     ·What information is exchanged between a VNF and a service control
>     entity? For example, how can a VNF Pool be addressed by the
>     service control entity?
>
>     ·After a VNF instance failover, how does the Pool Manager notify
>     the service control entity some characteristic changes of the VNF,
>     e.g., capacity change, but without disclosure of the pooling
>     procedure?
>
>     The WG initially focuses on several reliability mechanisms that
>     are mainly associated with a redundancy model based on a VNF Pool.
>     Additional mechanisms may include pool state maintenance only for
>     pooling purpose. Service state synchronization is out of scope for
>     this phase. The WGassumesthat a VNF Pool contains redundant VNF
>     instances of same functional type. Different types of VNFs are
>     envisioned to be held in separate VNF Pools. VNF Pool composed by
>     both virtualized and non-virtualized functional instances may be
>     included after further use case and requirements study. The WG
>     will address the reliability of an individual VNF, but not the
>     reliability related to the control or the routing between adjacent
>     VNFs that can form a network service.
>
>     Specifically, the WG will work on the following technical aspects:
>
>     ·Redundancy management within a VNF Pool, such as the signaling
>     between the Pool Manager and the instances in the pool for
>     instance registration, backup instances selection, and switching
>     between active and standby instances.
>
>     ·The protocol between the Pool Manager and the underlying network
>     to collect the network information required for appropriate
>     placement/selection of backup instances.
>
>     ·The protocol between a VNF and the service control entity to
>     exchange operational information between a VNF Pooland the service
>     control entity.
>
>     ·Identify and analyze reliable interfaces, such as transport
>     protocol like MPTCP and SCTP for reliable delivery of the messages
>     associated with the redundancy management within a VNF Pool.
>
>     ·Analysis of pooling security characteristics and requirements to
>     identify and mitigate threats against the pooling mechanism.
>     Identification of an appropriate trust model between pool members,
>     and between pool members and the Pool Manager.
>
>     The WG plans to deliver a problem statement, a set of use cases,
>     requirements and an architecture covering the aforementioned
>     technical aspects, and applicability and gap analysis of existing
>     technologies including but not limited to RSerPool. We will rely
>     heavily on existing IETF technologies, but that gaps will be found
>     around problems like redundancy mechanisms, state
>     maintenancesolely for pooling purposes, reliable transport, and
>     trust/security, all of which will need to be considered and
>     addressed. Although no decision on protocols will be made in this
>     phase, we will keep open for candidate protocols for VNF Pool. The
>     WG will seek re-chartering before adopting any work to develop
>     new, or extend existing, protocols.
>
>     In particular, we will work closely with the SFC WG, as we believe
>     that SFC and VNF Pool are independent but complementary. SFC would
>     essentially see a VNF Pool-enabled VNF as a normal service
>     function and therefore be able to merge it into an SFC just like
>     any other service functions. Just like the communication between
>     any pool users and VNF Pool, the information exchanged between the
>     VNF Pool and the SFC may include some operational information of
>     the VNF Pool.
>
>     Goals and Milestones:
>
>     December 2014 - Submit VNFPool Problem Statement to IESG for
>     publication as an Informational document.
>
>     April 2015 - Submit VNFPool Use Cases to IESG for publication as
>     an Informational document.
>
>     August 2015 - Submit VNFPool Requirements, including the
>     manageability of VNF Pool to IESG for publication as an
>     Informational document.
>
>     August 2015 - Submit VNFPool Architecture to IESG for publication
>     as an Informational document.
>
>     December 2015 - Submit one or more Applicability and Gap Analysis
>     of existing protocols to VNFPool to IESG for publication as
>     Informational document(s).
>
>     ==========================================================================
>
>     Your comments and suggestions to the charter are ALWAYS highly
>     appreciated!
>
>     Thanks.
>
>     -Ning
>
>     _______________________________________________
>
>     vnfpool mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/vnfpool
>