Subject: [IPsec] HA/LS terminology

From: Rodney Van Meter <[email-masked]>
Date: Wed, 24 Mar 2010 02:46:26 +0900

I am *NOT* an expert on fault tolerance, but I have studied it a
little (long ago, if not so far away), and I worked on Network
Alchemy's fault tolerant implementation of an IPsec gateway (a decade
ago, and a little farther away).  So, some suggestions on the
terminology for the HA&LS draft.

Terminology:

"High Availability" refers to a gateway or cluster whose expected
downtime is low on e.g. an annual basis.  High availability may be
achieved using fault tolerant techniques such as hardware/software
clustering.  It may also be achieved by e.g. using extremely robust
components and having a very low reboot time.

"Fault Tolerant" refers to a gateway or cluster that will maintain
service availability even when a specified set of fault conditions
occurs, such as the loss of one or more cluster members to a hardware
or software fault.

Clusters whose purpose is improving availability may operate using a
"hot standby" model, in which one or more gateways is active and one
or more gateways is held in reserve and activated when the failure of
an active member is detected.  Clusters whose purpose is improving
scalability (of performance, number of active connections, etc.),
using a "load sharing" model, have more than one member active.

IPsec gateways must be prepared for their peers to lose state, e.g. as
a result of a reboot, resulting in each peer attempting to reconnect.
The latency of that reconnection, and the computational load of
reconnecting a large number of peers, means that a fast-rebooting
gateway alone is not sufficient to provide high availability service,
driving the need for fault tolerance in an IPsec gateway
implementation.

If a fault is never visible to peers, the cluster is said to be
"completely transparent".  If some peers must reconnect, or a change
of IP address is visible, the cluster is said to be "partially
transparent".  It is possible to create an implementation with lazy
synchronization or an otherwise incompletely redundant state,
resulting in e.g. a few percent of peers (or a few percent probability
of any given peer) being aware of the fault.

		--Rod

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 23 Mar 2010 12:42:22 -0800 (ADT)

> terminology for the HA&LS draft.
[ ... ]

I think this is a really nice taxonomy and think it might be useful
to integrate it nearly as-is into the HA document.

Melinda

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 24 Mar 2010 05:51:41 +0900

> to integrate it nearly as-is into the HA document.

Go for it.  I can't promise more help (I'm in workload-shedding rather  
than workload-accreting mode right now), but if it's useful, it was  
worth an hour of my time to write up.

There *must* be a standard textbook/reference on FT/HA, but I'm out of  
date.

		--Rod

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Mar 2010 23:20:28 +0200

And thank you for taking the time, Rod.

The linktionary has a pretty good definition, though I don't know if it counts as "textbook". Same for Wikipedia
http://www.linktionary.com/f/fault_tolerance.html
http://en.wikipedia.org/wiki/Fault-tolerant_system

Anyway, we need to limit the scope of this document. I think we're only interested in clusters that provide high-availability, that are, to use your terms, completely or partially transparent.

Also, while there could be clusters with m members, where n, such that 1<=n<=m, are active, for the purposes of the discussion it is enough to assume that we're dealing with two types of high-availability, mostly transparent clusters:
- Those where exactly one does IKE and IPsec, and the rest just synchronize state, and
- Those where more than one member are doing IKE and IPsec, all the time synchronizing state.

This taxonomy is needed, because some of the problems that affect one cluster type do not affect the other.

So I propose the following terms, and these are not for generic clusters providing generic services to the generic Internet, but only for the purposes of this work item in this working group.

- For the cluster with just one member doing IKE and IPsec, I propose "hot-standby cluster"
- For the cluster with several members doing IKE and IPsec, I propose to keep "load-sharing cluster"

Is this fine with everyone?

Yoav

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 24 Mar 2010 06:30:22 +0900

> Is this fine with everyone?

I'm good with that, as long as we understand that both types of  
cluster may be either completely fault tolerant, partially fault  
tolerant, or not fault tolerant.  Of course, the taxonomy is simpler  
with only FT/not-FT, and most implementations will probably strive to  
be one or the other.

		--Rod

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 23 Mar 2010 13:31:57 -0800 (ADT)

> keep "load-sharing cluster"

I think "failover" is in broader use than "hot standby"
and would tend to prefer it myself, but I think either is clear.

Melinda

---

From: Rodney Van Meter <[email-masked]>
Date: Wed, 24 Mar 2010 06:35:39 +0900

On Mar 24, 2010, at 6:31 AM, Melinda Shore wrote:

>> - For the cluster with several members doing IKE and IPsec, I  
>> propose to
>> keep "load-sharing cluster"
>

I'm okay with "failover cluster" as a description of the cluster  
type.  For the node itself, I think referring to it as the "hot  
standby node" is probably a little clearer than the "failover node".

But I'm okay either way, I'll leave it to the actual document editor.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Mar 2010 23:43:01 +0200

> and would tend to prefer it myself, but I think either is clear.
I did not want to use "fault tolerant" because some would take that term is broad and sometimes taken to mean things I would not like to specify, like RAID arrays, and dual power supplies.  I don't think we should use this item to mandate that the two cluster members should not be connected to the same power strip.

Anyway, "failover cluster" is OK, except that we've already used "failover" to describe an event that happens to both types of clusters.  So I think we can stay with "hot standby" and "load sharing"

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 23 Mar 2010 18:05:52 -0700 (PDT)

Hi,

  "hot standby" implies a box sitting ("hot") twiddling its thumbs doing
little but waiting for another box to fail ("standby"). It's the VRRP
model.

  There is a HA model which supports dynamic load balancing as well as
active session failover. Nodes in such a cluster are not "standby". They
each have loads that they can shed and add to based upon some heuristic.
A neat attribute of such a system is that an IPsec SA can be established
on node A, move to node B after a while, and come back to A some time
later without any actual node failure. State moves around to keep the
cluster balanced.

  I would very much prefer "session failover" to "hot standby" and a
mild preference of "load balancing" over "load sharing". An HA model
doing VRRP could be termed "session failover" but the HA model described
above really can't be called "hot standby". And load can be shared but
just sharing a load can result in a mis-balanced cluster if sessions on
one node terminate naturally and it sits doing little while another node
whose sessions haven't terminated is huffing-and-puffing. Balancing can
imply sharing but not vice versa.

  regards,

  Dan.

On Tue, March 23, 2010 2:43 pm, Yoav Nir wrote:
>>> - For the cluster with several members doing IKE and IPsec, I propose
>>> to
> I did not want to use "fault tolerant" because some would take that term
> is broad and sometimes taken to mean things I would not like to specify,
> like RAID arrays, and dual power supplies.  I don't think we should use
> this item to mandate that the two cluster members should not be connected
> to the same power strip.
>
> Anyway, "failover cluster" is OK, except that we've already used
> "failover" to describe an event that happens to both types of clusters.
> So I think we can stay with "hot standby" and "load sharing"
>
> Yoav
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Mar 2010 04:24:30 +0200

> little but waiting for another box to fail ("standby"). It's the VRRP

And that's exactly what I want to describe. Well, not twiddling its thumbs. The standby is synchronizing state with the active member, but it's not doing any IKE or IPsec

> later without any actual node failure. State moves around to keep the

Failure is just used as an example of why a certain SA failed over to another member. It is by no means the only reason. Still, what you are describing is a model that provides both high-availability and load balancing, and that is the reason we're moving away from calling the first model "high availability".

> imply sharing but not vice versa.

"Session failover" sounds to me more like a description of an event than a type of cluster.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 24 Mar 2010 00:46:04 -0700 (PDT)

On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote:
> And that's exactly what I want to describe. Well, not twiddling its
> thumbs. The standby is synchronizing state with the active member, but
> it's not doing any IKE or IPsec

  Well don't use such a limiting term to describe a behavior that is
not so limited. Not all HA is that small subset you want to describe.

> Failure is just used as an example of why a certain SA failed over to
> another member. It is by no means the only reason. Still, what you are
> describing is a model that provides both high-availability and load
> balancing, and that is the reason we're moving away from calling the first
> model "high availability".

  Of course it's not the only reason. But you're missing the point. The
point is that the reason doesn't matter! You want to describe a particular
reason-- the "master" crashed and all state went over to the "hot standby"--
not the generic concept of state moving.

  So don't call it "high availability" then. But "hot standby" is worse.

> "Session failover" sounds to me more like a description of an event than a

  So what? Are you suggesting that a type of cluster that is not a
"hot standby" is not worthy of terminology in IPsecME?

  Your term is severely limiting. I like "session failover". If you don't
then come up with a term that generically describes HA and not the
particular style of HA that you are accustomed to.

  Dan.

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 24 Mar 2010 06:29:11 -0800 (ADT)

> not the generic concept of state moving.

Yes, I think this is my issue with the choice of "hot standby,"
as well - there's an implication that they're not sharing state
and that failing over looks from the outside like a reboot.

Melinda

---

From: Raj Singh <[email-masked]>
Date: Thu, 25 Mar 2010 12:18:31 +0530

+1
I agree with Dan.

On Wed, Mar 24, 2010 at 1:16 PM, Dan Harkins <[email-masked]> wrote:

> > "Session failover" sounds to me more like a description of an event than
> a
> > type of cluster.
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 25 Mar 2010 22:09:45 +0200

Hi Dan

I am not trying to create a complete taxonomy of cluster types. I should also note that we don't really have a term for a single "thing" that does IKE and IPsec. Our documents use terms like "gateway" and "peer", but "gateway" does not encompass VPN clients and hosts, and "peer" is not just any implementation, it's the *other* implementation. "Implementation" is a little too long.

Anyway, draft-ietf-ipsecme-ipsec-ha is not out to make a complete taxonomy of clusters. We only define what we need to discuss the problems. All the clusters that are of interest to us provide the ability for another member to take over the work of a failed member. Since this is common to all the clusters that we are considering, we don't need to define this specially. The only difference that matters is whether or not more than one member is handling traffic with the same peer at the same time.

So the only terminology that we need, the only taxonomy that we need, is for these two mutually-exclusive types of cluster:
- Only one member handles all traffic for a particular peer at the same time
- Several members handle traffic for a particular peer at the same time.

That's all the terminology that we need.

So with that in mind, what terms would you suggest for these two types of cluster?

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Mar 2010 00:59:31 +0200

Yoav Nir writes:
> I am not trying to create a complete taxonomy of cluster types.

I think it is worth adding more defined terms, just to show which we
are not talking about too. 

> I should also note that we don't really have a term for a single
> "thing" that does IKE and IPsec. Our documents use terms like
> "gateway" and "peer", but "gateway" does not encompass VPN clients
> and hosts, and "peer" is not just any implementation, it's the
> *other* implementation. "Implementation" is a little too long.

I would use host, or implementation, and I do not think implementation
is too long... 

> Anyway, draft-ietf-ipsecme-ipsec-ha is not out to make a complete
> taxonomy of clusters. We only define what we need to discuss the
> problems. All the clusters that are of interest to us provide the
> ability for another member to take over the work of a failed member.

I do not think that was clear from the terminology section. For
example the "load sharing cluster" and "cluster" does not really say
that.

If we add terms that describe different cluster types better, then we
can more clearly describe what we are really talking about.

One of the problems we have when talking about the ipsec-ha is that
people use different terms and they interpret them meaning different
things. Thats why I think it would be needed for this document to
define good and extensive terminology for this area and use those
terms consitently inside the document. 

> Since this is common to all the clusters that we are considering, we
> don't need to define this specially.

How can someone know that this is generic for all clusters, if you do
not define it?

> The only difference that matters is whether or not more than one
> member is handling traffic with the same peer at the same time.
> 
> So the only terminology that we need, the only taxonomy that we
> need, is for these two mutually-exclusive types of cluster:

I disagree. We do need much more extensive terminology to explain
also things we are not talking about, just to clarify that we do not
mean them. 
-- 
[email-masked]