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

Yoav Nir <ynir@checkpoint.com> Wed, 24 March 2010 02:24 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B37E3A67E1 for <ipsec@core3.amsl.com>; Tue, 23 Mar 2010 19:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.415
X-Spam-Level:
X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-HoEKwxZh4J for <ipsec@core3.amsl.com>; Tue, 23 Mar 2010 19:24:31 -0700 (PDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id DB6253A672E for <ipsec@ietf.org>; Tue, 23 Mar 2010 19:24:30 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2O2OWsd026790; Wed, 24 Mar 2010 04:24:32 +0200 (IST)
X-CheckPoint: {4BA97726-0-1211DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Mar 2010 04:24:53 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>
Date: Wed, 24 Mar 2010 04:24:30 +0200
Thread-Topic: [IPsec] Issue #177. (was: HA/LS terminology)
Thread-Index: AcrK+S+wAUq31EkTQ26Nyy/cyY/g9A==
Message-ID: <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com>
References: <7EF09073-9D20-4077-A8DD-59B84B1732D0@sfc.wide.ad.jp> <7bc30fde97954c9f651eb436c822dab7.squirrel@webmail.arsc.edu> <118D7A1E-6090-4D71-9FEB-89AEB189CA94@sfc.wide.ad.jp> <1699285A-BDB7-40A6-BA58-5228AAE1133A@checkpoint.com> <1eac10bbf0fee9817dbc4c681868daa2.squirrel@webmail.arsc.edu> <3B0BF1DE-83E0-413E-A09E-146F8B2C7C9B@checkpoint.com> <f0aa47a3042adbe0b70d3befbcc8f468.squirrel@www.trepanning.net>
In-Reply-To: <f0aa47a3042adbe0b70d3befbcc8f468.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>, "ipsec@ietf.org" <ipsec@ietf.org>, Melinda Shore <shore@arsc.edu>
Subject: Re: [IPsec] Issue #177. (was: HA/LS terminology)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2010 02:24:32 -0000

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

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

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

> 
>  regards,
> 
>  Dan.