King, Daniel
2014-03-12 15:50:06 UTC
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
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