Re: [IPsec] Issue #177. (was: HA/LS terminology)

"Dan Harkins" <> Wed, 24 March 2010 07:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C98B23A6A4A for <>; Wed, 24 Mar 2010 00:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.905
X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id euoQ0G3NhjQp for <>; Wed, 24 Mar 2010 00:45:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EFE5A3A6A49 for <>; Wed, 24 Mar 2010 00:45:43 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id D1DC61022404A; Wed, 24 Mar 2010 00:46:03 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 24 Mar 2010 00:46:04 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 24 Mar 2010 00:46:04 -0700 (PDT)
From: "Dan Harkins" <>
To: "Yoav Nir" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: Rodney Van Meter <>, "" <>, Melinda Shore <>, Dan Harkins <>
Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Mar 2010 07:45:44 -0000

On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote:
> On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
>>  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.
> 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.

>>  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.
> 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.

>>  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.
> "Session failover" sounds to me more like a description of an event than a
> type of cluster.

  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.