Re: [vnfpool] VNFPool BoF Minutes

"Holmes, David W [CTO]" <David.Holmes@sprint.com> Wed, 12 March 2014 18:44 UTC

Return-Path: <David.Holmes@sprint.com>
X-Original-To: vnfpool@ietfa.amsl.com
Delivered-To: vnfpool@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81961A0755 for <vnfpool@ietfa.amsl.com>; Wed, 12 Mar 2014 11:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] 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 9e6UiFMciJOz for <vnfpool@ietfa.amsl.com>; Wed, 12 Mar 2014 11:44:48 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3801C1A0479 for <vnfpool@ietf.org>; Wed, 12 Mar 2014 11:44:48 -0700 (PDT)
Received: from mail205-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Mar 2014 18:44:42 +0000
Received: from mail205-co9 (localhost [127.0.0.1]) by mail205-co9-R.bigfish.com (Postfix) with ESMTP id D58E790018D; Wed, 12 Mar 2014 18:44:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPV:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI
X-SpamScore: -22
X-BigFish: VS-22(zz9371I542I4015I14ffIzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25f6h2605h262fh9a9j1155h)
Received-SPF: pass (mail205-co9: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=David.Holmes@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ;
Received: from mail205-co9 (localhost.localdomain [127.0.0.1]) by mail205-co9 (MessageSwitch) id 1394649879946837_8571; Wed, 12 Mar 2014 18:44:39 +0000 (UTC)
Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.241]) by mail205-co9.bigfish.com (Postfix) with ESMTP id DB839C40062; Wed, 12 Mar 2014 18:44:39 +0000 (UTC)
Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Mar 2014 18:44:38 +0000
Received: from PDAWEH04.ad.sprint.com (pdaweh04.corp.sprint.com [144.226.111.59]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id s2CIiW1N014443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Mar 2014 13:44:36 -0500
Received: from PLSWE13M02.ad.sprint.com (144.229.214.21) by PDAWEH04.ad.sprint.com (144.226.111.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Mar 2014 13:44:33 -0500
Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by plswe13m02.ad.sprint.com (2002:90e5:d615::90e5:d615) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 12 Mar 2014 13:44:22 -0500
Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0775.031; Wed, 12 Mar 2014 13:44:22 -0500
From: "Holmes, David W [CTO]" <David.Holmes@sprint.com>
To: "King, Daniel" <d.king@lancaster.ac.uk>, "vnfpool@ietf.org" <vnfpool@ietf.org>
Thread-Topic: VNFPool BoF Minutes
Thread-Index: Ac8+Ckp89QGGYom6Q4e9wO17cx/NwwAF9THg
Date: Wed, 12 Mar 2014 18:44:21 +0000
Message-ID: <5cc46b54cca24a3c87debc89fc6dd6f6@PLSWE13M01.ad.sprint.com>
References: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local>
In-Reply-To: <65174429B5AF4C45BD0798810EC48E0A11429D@EX-0-MB2.lancs.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.123.104.24]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CRA-Verdict: 144.229.32.56$lancaster.ac.uk%0%1%sprint.com%False%False%0$
X-OriginatorOrg: sprint.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%0$Dn%LANCASTER.AC.UK$RO%1$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/vnfpool/kQN28kVPH2-Lyy3AworPCi-IeFU
Cc: Melinda Shore <melinda.shore@nomountain.net>, 'Zongning' <zongning@huawei.com>
Subject: Re: [vnfpool] VNFPool BoF Minutes
X-BeenThere: vnfpool@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for virtual network function resource pooling." <vnfpool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vnfpool>, <mailto:vnfpool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vnfpool/>
List-Post: <mailto:vnfpool@ietf.org>
List-Help: <mailto:vnfpool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vnfpool>, <mailto:vnfpool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 18:44:52 -0000

Hi Daniel et al,

Being something of an IETF newbie, I'm not sure as to how any decisions/recommendations/feelings on how this topic will proceed (i.e. @ IETF90) would be recorded.

Specifically, as I recollect, the outgoing assumption was that this was not a topic yet ripe for the creation of a WG, but I don't see how this was recorded; or maybe it is by omission; i.e. no positive statement to move to a WG?

Thanks,

David Holmes

-----Original Message-----
From: vnfpool [mailto:vnfpool-bounces@ietf.org] On Behalf Of King, Daniel
Sent: Wednesday, March 12, 2014 8:50 AM
To: vnfpool@ietf.org
Cc: Melinda Shore; 'Zongning'
Subject: [vnfpool] VNFPool BoF Minutes

Hi All,

Please find the VNF Pool BoF Minutes below. If you have any clarifications or updates please let me know.

Br, Dan.

===================================

VNFPool BoF Draft Agenda, IETF 89th, London.
Viscount, Tuesday Morning Session I, 0900-1130 GMT, March 4, 2014.

09:00 Admin (Chairs, 5 minutes)
No Agenda changes.

09:05 Introduction & Purpose of the BoF (Chairs, 5 minutes)

09:10 Problem Space (35 minutes)
        1) Problem Statement (Melinda, 15 minutes)
        https://datatracker.ietf.org/doc/draft-zong-vnfpool-problem-statement/

Comments at microphone, discussion points and actions:

- Clarification that the work should not overlap within IETF or anywhere else.

- [Chairs]: VNF Pool effort is mostly concerned with solving unique problems in IETF.

- Request to see if any business discussion for reliability function has been conducted.

- [Chairs]: Effort concerned with reliability that has been identified by service providers and customers highlighting their problems (in use cases).

- Suggested that performance monitoring should also be considered, in context of performance degradation and VNF Pool switching.

Question: Why not Hardware devices?  [Chairs]: VNF Pool is applicable to hardware but for now the context is virtual network devices.

- Request to make sure charter reflects problem statement, and vice versa.

- Security of state sharing is a concern.  The security section of the problem statement, but you do not look at security state. Bob suggested that security between VNFs, when state sharing, should also be considered. [Bob Moskowitz]

- Maybe some requirements from the Fixed Mobile Convergence (FMC) work.

- Request to look at existing IETF protocols for configuration of devices and DNS (OPS-NM AD: Benoit Claise).

Action: Synch Problem Statement with Charter text

Action: Coordination with SFC to agree on scope and perceived overlap would be helpful.

Action: Security must be investigated for security of solution, and security of state passing in the VNF Pool.

Action: Clarify business case(s) in summary of use cases.

        2) Q & A (all, 20 m minutes)

09:50 Use Cases (50 minutes)

        1) Generic Use Case (Michiaki, 5 minutes)
        https://datatracker.ietf.org/doc/draft-xia-vnfpool-use-cases/

        2) vEPC Use Case (Marco, 10 minutes)
        https://datatracker.ietf.org/doc/draft-king-vnfpool-mobile-use-
        case/

Comments at microphone, discussion points and actions:

- Software/Virtualization resilience is a reasonable requirement.

- Some participants felt that it was unclear if we are discussing a VM Pool or VNF Pool. The Chairs clarified that this was not VM pooling.

- [Kireeti Kompella]: Is it then groups of virtual functions and multiple pools?

- Suggestion that the work should deal with hardware and not just virtualised Network Functions (vNF).

- Observation that SFC charter does not mention virtualisation.

- A number of factors exist in vEPC that may be unique for providing reliance in a virtualised environment.

- State management may be required, but in some cases it may be acceptable to simply recover.

- Consideration of the role of VNF Pool Manager.

- A need to mindful of not over reaching on requirements, is synchronization of state feasible and is it reasonable to expect state sharing between vendor implementations.

- Dave Dysan:  The recovery of virtual components is beneficial.  The VNF can be a connected set of VMs. You can utilize a set of work from the Reliable Server pooling (RSerPool)

- Thomas Nordmark: The link between virtual network functions and the synchronized pool is not clear in this presentation, and it seems to be different from the previous definition of pools and pool manager.

- Daniel King: The uses were developed in isolation, and additional synchronization of terminology needs to occur.

Action: Synch terminology across VNF Pool I-Ds, including Use Case documents.

Action: Continue to develop Use Case I-Ds to help identify if State Synchronization is a reasonable requirement, and what is the scope of the required state synchronization.

        3) Load Balancing (Andy, 5 minutes)

Comments at microphone, discussion points and actions:

- Suggestion that if SFC is correctly implemented then this [the load
balancing scaling issue] should not be applicable.    (Eric Nordmark and
Jim Beecher)

- Service graph and pooling are separate things, how the virtual network function is pooled should be abstracted away from SFC.  (Kireeti
Kompella)

- Assertion that SFC can provide the required solution.

- State Sharing interacts with the service graph.  Where these functions touch, it will be important to keep the functions separate in the interaction.  [Erik Nordmark]

- Request to help clarify this [load balancing] problem to help with WG assignment (VNF Pool, SFC, or other).

- VNF Pool is building on ETSI NFV architecture and does not describe the internal architecture of a VNF.

- SFC is a special case of service graph and is not addressing what we [VNF Pool] is investigating.

- Request to look at the scaling of the solutions (Thomas Narten)

- Constantine: The Unify European project is investigating functions like the VNF Pool.

Action: Describe and document requirements for the load balancing scenario in a use case I-D.

Action: Investigate comment that SFC can provide the required solution
for load balancing described in the presentation.

Action: If the SFC + VNF Pool are required to solve the load balancing problem, determine where the points of interaction with SFC are and develop clean interfaces so that SFC and VNF Pool remain separate entities.

Action: Look at scaling of VNF Solution.

        3) vCDN Use Case (Pedro, 10 minutes)
        https://datatracker.ietf.org/doc/draft-aranda-vnfpool-cdn-use-case/

Comments at microphone, discussion points and actions:

- Echo from other operator that CDN is a useful use case for operators.

- Important to note that policy applies to resource management. A gap analysis and I-D might also be needed.

Action: Investigate resilience resource policy requirements.

        4) Resource Pool Use Case (Sue, 10 minutes)
        https://datatracker.ietf.org/doc/draft-hares-vnf-pool-use-case/

- Suggestion that a recent paper submitted to the SDN RG list might help highlight existing/new requirements.
        5) Q & A (all, 10 minutes)

10:35 Related Works (15 minutes)
        1) RSerPool Applicability (Thomas, 10 minutes)
        https://datatracker.ietf.org/doc/draft-dreibholz-vnfpool-rserpool-applic/

Comments at microphone, discussion points and actions:

- Suggestion that the RSerPool work should have been presented first (Dave Dysan)

- If used, the RSerPool work is Experimental (Status) so would have to be published as Standards Track.

- RSerPool work was shutdown years ago, but it represents an opportunity to restart and develop as needed.

- [NTT person): Would there be multiple network functions operating as VNF Pools?

- Suggestion that SCTP is used but MSCTP might be an alternative (Randall Stewart, Jabber)

- Are the assumptions previous used in the development of RSerPool still valid?

- System architecture should have inherent redundancy, the [RSerPool authors] should analyse the impact of RSerPool.

- A number of future research is documented in RSerPool Next Generation I-D.

- RSerPool will require 64 bit capability.

10:50 Charter Discussion (30 minutes)

        1) Charter (Chairs, 5 minutes)
        http://www.ietf.org/mail-
        archive/web/vnfpool/current/msg00224.html

Comments at microphone, discussion points and actions:

- Some discussion already on scope of protection for both internal and external functions.  Some discussion on time dimension in the scope of protection.  Also the protection may also be participating in a larger protection scheme.

- What is the server application that is being examined?  Does it need reliability of pools?

- [Jamal Salim]: The VNF pool application is describing high availability that MPLS and GMPLS utilize.  ForCES has High availability based on Forces running over a control.  Based on the ForCES experience, it is important to know are these functions highly available or not?

- [unknown]: Do we have flow stitching?

- Not total agreement that work should be independent of SFC.

- Current fate sharing, load balancing, pool function are not fit for purpose.  These are problems that need to be worked on.

- UNIFY is a European Research project investigating the problem space, some shared findings/discussion may be beneficial.

- It would be valuable to coordinate within a VNFPool. If you extend it to inter-pools, it becomes "orchestration".

- Observation that a pool of NFs, in a virtual FW you have higher failure rate.

- Hardwire based solutions have built in redundancy, network function resiliency, and the drafts (problem or use cases) do not state how to use this.

- Scepticism that flow forwarding  state synchronisation can be achieved. Also do operators really require this capability?

- Question: What is in-scope versus out-of-scope?  Do we handle service state recovery?

- The service state recovery is beyond the scope of SFC.

- [Jim Beecher] Service availability is not in scope.

- [Eric Nordmark}: Are there people that can help us with fate sharing within the NFV Pool functions?

- [George (from Greece)]: In the virtual clusters fate sharing, load balancing and pool functions are not yet working.

- Linda Dunbar: What happens if one instance fails which is not a routing instance?

- Thomas Narten: Sceptical whether IETF has the expertise to examine the state synchronization issue.  IETF does not have large amounts of firewall vendors.

- [Sue Hares]: Today's access devices all contain first level firewalls so all access devices have now installed firewalls. The more common firewall is this firewall within the access device.

Action: We need a common understanding between VNF POOL and SFC as to scope of work.

Action: Determine scope of protection for internal and external functions.

Action: Consider what applications (or class of applications) might utilize VNF Pool.

Action: Clarify the architecture aspect of VNFPOOL, what is in scope,
and what is out of scope.

Action: Definition of a VNF, is there a VNF, SFC VNF and ETSI VNF? Where is overlap, can we agree definitions.

Action: Operators need to discuss if FW state synchronisation, or indeed other NF state synchronisation, is actually required.

Action: Examine how the need for high availability impacts the VNF Pool design and

Action: Examine failures scenarios if one instance fails.

Action: Examine existing solutions to determine if some existing IETF protocol or design fits most of the parameters.  This is the concept of re-use rather than reinvent due to NIH (not-invented here).

        2) Open Discussion (all, 25 minutes)

11:20 Wrap-up (Chairs, 10 minutes)

11:30 End


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.