Re: [IPsec] Issue #177. (was: HA/LS terminology)
Raj Singh <rsjenwar@gmail.com> Thu, 25 March 2010 06:48 UTC
Return-Path: <rsjenwar@gmail.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 105913A6452 for <ipsec@core3.amsl.com>; Wed, 24 Mar 2010 23:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Level:
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
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 vhJmb-V3awTJ for <ipsec@core3.amsl.com>; Wed, 24 Mar 2010 23:48:15 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id BCD673A6CA8 for <ipsec@ietf.org>; Wed, 24 Mar 2010 23:48:14 -0700 (PDT)
Received: by gwj23 with SMTP id 23so1535560gwj.31 for <ipsec@ietf.org>; Wed, 24 Mar 2010 23:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZteBYVoH3J/2bW2uOQlhLNzB+QN9iNoqlGfu/J0wCyA=; b=TP/ueWzbptls4kJZH87bHqCwClaxCix6ClRBKIxGzjl9/iQNODbX7drBFusEKNTSac yDjh7BssqRa3RQZRXbYrfb0dWeUh0P5iOpv0jwxBrbJOOZXhyyz5eJWH8hmd1te9AeLe t8wNxBFSgbsKUefIjdNw19RvcERXS/UFVzHQs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J55AxOLj+OG5URuaHxJXkYy3rPebv4Hb64tMNZCaMAUiGQSQIvKh0cC37sKVTH7pQT 9fIQPFm1Q+exCK5sBeJ0yEOCzr13JXHkyzbHHSgw2/npqt3dTZMWxd1uSxFbn1Clh1eK NJdREy27MWYPlTPt8xI+qv/lesbcjNOlhTSJs=
MIME-Version: 1.0
Received: by 10.90.14.16 with SMTP id 16mr779645agn.47.1269499711466; Wed, 24 Mar 2010 23:48:31 -0700 (PDT)
In-Reply-To: <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net>
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> <6AA54FAA-419E-4887-9801-227AABBCD702@checkpoint.com> <03e919e078c06550481ad5f272511dd0.squirrel@www.trepanning.net>
Date: Thu, 25 Mar 2010 12:18:31 +0530
Message-ID: <7ccecf671003242348r119d3bd4uce7f70a226aeff3b@mail.gmail.com>
From: Raj Singh <rsjenwar@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="0016361646bf582ddc04829a6ffb"
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>, "ipsec@ietf.org" <ipsec@ietf.org>, Melinda Shore <shore@arsc.edu>, Yoav Nir <ynir@checkpoint.com>
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: Thu, 25 Mar 2010 06:48:16 -0000
+1 I agree with Dan. On Wed, Mar 24, 2010 at 1:16 PM, Dan Harkins <dharkins@lounge.org> wrote: > > 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. > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
- [IPsec] HA/LS terminology Rodney Van Meter
- Re: [IPsec] HA/LS terminology Melinda Shore
- Re: [IPsec] HA/LS terminology Rodney Van Meter
- [IPsec] Issue #177. (was: HA/LS terminology) Yoav Nir
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Rodney Van Meter
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Melinda Shore
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Rodney Van Meter
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Yoav Nir
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Dan Harkins
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Yoav Nir
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Dan Harkins
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Melinda Shore
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Raj Singh
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Yoav Nir
- Re: [IPsec] Issue #177. (was: HA/LS terminology) Tero Kivinen