Subject: Re: [vnfpool] pool manager for state sync?

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Dec 2013 12:35:24 -0500

Thomas and Ning: 

This another post in my chain of post to ask questions from past email.  

Questions:  

Is the charter written to allow state synchronization via a process that
does "state synchronization for VNF" to be done in another network service
(E.g. ISIS/OSPF/BGP/VRRP), and the VNF Pool manager interacts with that
demon to get state synchronization?  

I’ve included below the charter text that this question impacts. 

It is unclear if the VNF Pool architecture in problem statement
(draft-zong-vnfpool-problem-statement-01) address this point. 

Reason: 

The state synchronization on the VNF Pool, PE, PU requests, and PM load is
critical to allow virtualization . This state synchronization is part of the
L1-L7 state synchronization I mentioned in my previous post.  The state
synchronization allows you to know fate sharing, and individual layers.
(See Fate sharing info below). 

How: The concepts of L1-L7 state sharing of critical information being done
a separate demon (link-state/BGP/hybrid) is possible.  It can be a single
demon running 1 or many protocols. 

Problem space text impacted 

------------------------------------------------

a)      Signaling between VNF pools for transition (e.g. state change,
scaling, moving) notification, backup announcement;

b)       Identification and evaluation of state sharing mechanisms,
including (but not limited to) distributed shared memory, gossip protocols,
pfsync, and state check pointing;

c)        Exchange of reliability related information between VNF pools and
underlying network (e.g. interfacing with ALTO, I2RS);

d)       Identify and analyze reliable transport characteristics for control
plane traffic;

e)       Analysis of transport security characteristics to provide
protection against known threats, and identification of an appropriate trust
model;

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

Examples of L1-L4, L7 critical information that impacts VNF Pools 

1) Physical connectivity has change 

                a) optical fiber cuts may cause fate sharing with a lot of
work;

                b) WiFi /LTE activity is key to the critical
SMS/Message/VOIP 

                (E.g. Hospitals Monitoring failures within the hospital of
WiFi failures.

                  It is important to know where status messages can go.) 

2) L2 connectivity 

                a) Data centers need to have TE in TE in order to move
critical traffic around

                b) LTE/Wifi connectivity in the home to Financial
Brokers/Medical/Insurance

                A SOHO router for key  small cell devices needs to
prioritize the critical traffic vs. normal traffic. 

3) Network connectivity and status 

                a) Tier 1 to Tier 3 providers may have failures or
re-routing

                b) Brokers pay top dollar to have ultra-fast service 

                 the Firewall/LB or Security status is monitored tightly and
corrected quickly 

4) Transport service - and WAN optimization 

                a) Balanced and fully utilized TCP provides 90-95%
utilization of WAN (by avoiding TCP Sawtooth)

                b) TCP pipes over mobile link also provides WAN optimization

                Status on these links in critical fashion allows the TCP to
be balanced. 

5) application location services 

                a) load on application services for critical applications
(web or processing)

                b) Pool availability 

Final comment on State:  If you think this is too much, please note that the
ADARA code base has this in deployed product for edge routers, servers, and
mobile devices. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Dreibholz
Sent: Monday, September 30, 2013 4:01 AM
To: Zongning
Cc: [email-masked]; Michael Tuexen; Melinda Shore
Subject: Re: [vnfpool] pool manager for state sync?

Hi,

Torsdag 26. september 2013 07.09.20 skrev Zongning:

> Hi, all,

> In current RSerPool mechanism, the service states (for stateful 

> service like

> FW) are synchronized between active and backup servers via the relay 

> of pool user. This approach works fine assuming that pool user is stable.

> Consider the VNF pools model where a pool user (i.e. user of 

> downstream pool according to service chain) is normally a VNF instance 

> in its own pool, and pool user and even its backup instances are likely
less stable.

> As such, storing critical service states information in VNF instances 

> would be a problem. I'd think a feasible approach would be to use pool 

> manager for service states synchronization, e.g. retrieving, storing, 

> distributing service states amongst VNF instances? Comments are highly
appreciated!

This sounds useful.

Originally, RSerPool did not intend to define any state synchronisation. But
ASAP has the ASAP Cookie/ASAP Cookie Echo mechanism built in, because it is
very simple and therefore easy to implement and may be useful for a number
of applications. It is, however, somewhat limited: the cookie size is < 64
KiB, the state should not change too often to avoid network overhead, and
security has to be ensured so that a malicious PU does not use the same
cookie for resumption on multiple PEs.

Since VNF is a specific application, it makes sense to define a specific
state synchronisation approach. May be, "state synchronisation for VNF"
could be another service on top of RSerPool? That is, RSerPool would not be
modified to add state synchronisation but a service that realises it could
be realised based on RSerPool? This would separate the application-specific
task from the pool management task. Of course, pool management (i.e. the PR)
and state synchronisation management could be deployed on the same machines.

--

Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

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

Thomas Dreibholz

Simula Research Laboratory

Simula Innovation AS, Network Systems Group  Visiting address: Martin Linges
vei 17, 1364 Fornebu, Norway  Mailing address:  P.O.Box 134, 1325 Lysaker,
Norway

-----------------------------------------------------------------------

E-Mail:      <mailto:[email-masked]> [email-masked]

Homepage:    <http://simula.no/people/dreibh> http://simula.no/people/dreibh

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