Re: [IPsec] Issue #177

Looks good. A few comments down below.

	Yaron

On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote:
> Hi all.
> 
> As the previous discussion on this topic showed, the WG would like a more thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up with so far. Please send comments to the list.
> 
> 2.  Terminology
> 
>    "Single Gateway" is an implementation of IKE and IPsec enforcing a
>    certain policy, as described in [RFC4301].
> 
>    "Cluster" is a set of two or more gateways, implementing the same
>    security policy, and protecting the same domain.  Clusters exist to
>    provide both high availability through redundancy, and scalability
>    through load sharing.
> 
>    "Member" is one gateway in a cluster.
> 
>    "High Availability" is a condition of a system, not a configuration
>    type.  A system is said to have high availability if its expected
>    down time is low.  High availability can be achieved in various ways,
>    one of which is clustering.  All the clusters described in this
>    document achieve high availability.
> 
>    "Fault Tolerance" is a condition related to high availability, where
>    a system maintains service availability, even when a specified set of
>    fault conditions occur.  In clusters, we expect the system to
>    maintain service availability, when one of the cluster members fails.

one or more

> 
>    "Completely Transparent Cluster" is a cluster where the occurence of
>    a fault is never visible to the peers.
> 
>    "Partially Transparent Cluster" is a cluster where the occurence of a
>    fault may be visible to the peers.
> 
>    "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of
>    the members is active at any one time.  This member is also referred
>    to as the the "active", whereas the others are referred to as "stand-
>    bys".  [VRRP] is one method of building such a cluster.

[Please ignore if you're sick and tired of terminology discussions:] I
look at the term "hot standby" as contrasted with "warm/cold
standby" (see http://www.webopedia.com/TERM/H/hot_standby.html). This is
not what we mean here. Can we use "active-standby" instead?
> 
>    "Load Sharing Cluster", or "LS Cluster" is a cluster where more than
>    one of the members may be active at the same time.  The term "load
>    balancing" is also common, but it implies that the load is actually
>    balanced between the members, and we don't want to even imply that
>    this is a requirement.
> 
>    "Failover" is the event where a one member takes over some load from
>    some other member.  In a hot standby cluster, this hapens when a
>    standby memeber becomes active due to a failure of the former active
>    member, or because of an administrator command.  In a load sharing
>    cluster this usually happens because of a failure of one of the
>    members, but certain load-balancing technologies may allow a
>    particular load (an SA) to move from one member to another to even
>    out the load, even without any failures.

The parenthetical "an SA" implies that SAs are never shared between
members. I suggest that the initial definition of "cluster" mention
whether we expect IKE and IPsec SAs to be shared between members.

> 
>    "Tight Cluster" is a cluster where all the members share an IP
>    address.  This could be accomplished using configured interfaces with
>    specialized protocols or hardware, such as VRRP, or through the use
>    of multicast addresses, but in any case, peers need only be
>    configured with one IP address in the PAD.
> 
>    "Loose Cluster" is a cluster where each member has a different IP
>    address.  Peers find the correct member using some method such as DNS
>    queries or [REDIRECT].

Upon failure, members' IP addresses are reallocated to other members.

> 
>    "Synch Channel" is a communications channel among the cluster
>    members, used to transfer state information.  The synch channel may
>    or may not be IP based, may or may not be encrypted, and may work
>    over short or long distances.  The security and physical
>    characteristics of this channel are out of scope for this document,
>    but it is a requirement that its use be minimized for scalability.
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec