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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
