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

[LAC Chidung <[e-mail]>]

Linda,
1) IMHO, the difficulty is to marry the pool and the NFV scaling in/out 
concepts. Actually, the lower part of the picture (called "VNF") should 
be appropriate to the NFV environment, but using the expression "pool" 
for it is not necessary, i.e., what means "pool" in the case where a 
single VNF instance is sufficient to treat the load ? We definitively 
need to comprehend "pool" differently (compared to the PNF context) ...
If scaling in/out is used, it is hard to imagine how to exempt the 
architecture from including a mechanism to distribute the load among the 
different instances.
Furthermore, as Ning wrote to Adrian on June 27th "/You are right that a 
VNF pool appears as a single instance to outside entity such as service 
control entity/": as the pool is hidden, the load sent to the pool's 
elements (VNF instances in the NFV context) goes necessarily to a single 
address (which could be redundant for HA purposes), leaving to this 
entity the job to distribute the load.
2) If "/the Model 1/" = no redundancy, IMO, stateful/stateless and 
no_redundancy/redundancy are independent. If there is a need for (high) 
availability, stateless VNF redundancy should be carried out (and is 
usually much more easy than stateful redundancy).
Best,
Chidung

Le 01/07/2014 01:17, Linda Dunbar a écrit :
>
> Chidung,
> A few questions to your attached file:
> -All the models assume that there is a central LBM that traffic 
> traverse through. I would think that VNFpool doesn’t require the 
> traffic to go through a single point of LB. Correct?
> -1+1 protection can be very expensive. I would think only the stateful 
> VNF might need 1+1 or N+K protection. For stateless VNF, the Model 1 
> should be used.
> My two cents,
> Linda
>
> *From:*vnfpool [mailto:[e-mail]] *On Behalf Of *LAC 
> Chidung
> *Sent:* Friday, June 27, 2014 4:24 AM
> *To:* Zongning
> *Cc:* [e-mail]
> *Subject:* Re: [vnfpool] 答复: 答复: 答复: Updated VNFPool Charter
>
> Hi Ning,
> 1- On further consideration, my remark (i) in the previous e-mail 
> ("/no redundancy at all ...../") should not be applied in the VNF 
> context if the intention is to use a pool for redundancy purposes 
> *while minimizing the needed resources*. As shown in the figure 
> enclosed, this PNF scheme (no redundancy at all, i.e., all instances 
> of the pool participate actively) is not applicable in the VNF 
> framework where additional instances are created *only* if needed.
> 2- Back to your e-mail of June 19th "/the VNF instance scaling within 
> a VNF pool is included in the charter/": I don't think "scaling", 
> "scalability" appearing in the charter - it would be nice to introduce 
> a sentence (somewhere) with one of these two words to avoid this 
> ambiguity. Again, scaling in/out is one main characteristic of VNF.
> Best,
> Chidung
>
> Le 27/06/2014 03:36, Zongning a écrit :
>
>     Hi, Chidung,
>     Thanks for your suggestions. I will make the text clear for
>     comment Z2. But for comment Z9, I’d prefer to keep “VNF Pool”, as
>     we don’t propose/discuss a concrete VNF Pool architecture in the
>     charter, but just introduce a general concept.
>     Look forward to your further comments.
>     -Ning
>
>     *发****件人**:*LAC Chidung [mailto:[e-mail]]
>     *发****送时间**:*2014年6月26日22:53
>     *收件人**:*Zongning
>     *抄送**:*[e-mail] <mailto:[e-mail]>
>     *主题**:*Re: 答复: [vnfpool] 答复: Updated VNFPool Charter
>
>     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 perceive  the 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] <mailto:[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 WG
>             assumes that 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
>