Subject: [vnfpool] RSerPool protocol experience

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Sep 2013 16:05:27 -0400

Hi.

Given the RSerPool is mentioned in
draft-zong-vnfpool-problem-statement-01.txt, can someone summarize
what experience we have with the RSerPool protocols?

I believe they were published as experimental protocols. Have they
been implemented in any products? Do we have any deployment experience
with them?

Thomas

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2013 12:21:02 -0800

> been implemented in any products? Do we have any deployment experience

I co-authored a few of those documents and I know of no
deployments.

I was concerned when I first saw rserpool in the vnfpool
documents, but here's my take on it:

1) rserpool was not a good answer to the problem that
   it purported to address.  The principal authors had a hammer
   (SCTP) and wanted to pound things.  They failed to
   adequately address core problems around state sharing,
   synchronization, etc. - distributed computing problems

2) It's fine for providing a pooling mechanism, but an
   actual application built around it will require significant
   effort

3) the VNF reliability problem is probably a pretty good
   use of rserpool, as long as the work is properly scoped
   and the charter is very, very clear about what would
   need to be done.  This is not really a distributed
   computing problem.

To summarize, I think that the core problems with rserpool
have to do with its nearly complete inadequacy as a telephony
gateway and/or switch pooling solution.  That doesn't mean
that it's inapplicable to other problems.

-- 
Melinda Shore
No Mountain Software
[email-masked]

"Software longa, hardware brevis."

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Sep 2013 22:35:57 +0200

>   (SCTP) and wanted to pound things.  They failed to
The original motivation, as far as I remember, was to
have a common server pooling for the various SIGTRAN layers.
Currently, they all have their own... Just like SCTP is
was the common transport layer for them.
>   synchronization, etc. - distributed computing problems
If I remember it correctly, state sharing was explicitly out
of scope for the WG. See
http://datatracker.ietf.org/wg/rserpool/charter/

However, it provides a way for state synchronisation for
the ENRP name space.
>   need to be done.  This is not really a distributed
Agreed.

Best regards
Michael
> _______________________________________________
> vnfpool mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vnfpool
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Sep 2013 01:38:30 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Wednesday, September 18, 2013 4:21 AM
To: [email-masked]
Subject: Re: [vnfpool] RSerPool protocol experience

[Qin]: I know rserpool is good at selecting a set of pool elements that provide the same type of service.
However can reserpool be used to select a set of instances that provide various different type of service, e.g., firewall, Load balancing.
Can reserpool be used to select a set of instances that follows specific order?
Can rserpoool be used to provide different level of reliability based on the number of backup instances to be choosen and location proximity of these instances?

---

From: Zongning <[email-masked]>
Date: Wed, 18 Sep 2013 01:57:31 +0000

Hi, Michael and Melinda,

If I remember correctly, there is "cookie" method documented in ASAP RFC to address the application state sharing between serving instance and its backup for failover.
My current feeling is that this mechanism can be applicable to VNF pools. But there could be potential extension as well? How do you think?

Another interesting point I found is about the backup announcement. Again, in ASAP, there is "business card" mechanism to announce the backup instance. However, in VNF pools, considering the fact that the backup instance could suffer from dynamic such as migration, failure, we probably need to consider effective approach for backup update, e.g., sending period, push/pull...?

Thanks.

-Ning

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Michael Tuexen
> Sent: Wednesday, September 18, 2013 4:36 AM
> To: Melinda Shore
> Cc: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Sep 2013 18:15:00 -0800

On 9/17/13 5:57 PM, Zongning wrote:
> If I remember correctly, there is "cookie" method documented in ASAP
> RFC to address the application state sharing between serving instance
> and its backup for failover. My current feeling is that this
> mechanism can be applicable to VNF pools. But there could be
> potential extension as well? How do you think?

Right, but no.  It's really not adequate for high
availability, for a couple of reasons.  One is that
the cookie is underspecified for use for what is
potentially a very large amount of data (for highly
stateful network functions) and that the delivery
(cookie handling) description is also underspecified
for high availability, where there can be timing
issues, questions about what "reliability" actually
means, and so on.  There's a reason that these
documents were published as experimental standards.

My expectation is that ENRP is likely to be far
more useful to this effort than ASAP.  But, it's
very early in the process and there may or may not
be more applicable alternatives to rserpool.

Melinda

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 17 Sep 2013 22:53:05 -0400

> be more applicable alternatives to rserpool.

The discussions made me feel that the Zookeeper
architecture could be an alternative to be looked into.

Richard

>
> Melinda
>
>
> --
> Melinda Shore
> No Mountain Software
> [email-masked] <javascript:;>
>
> [email-masked] <javascript:;>