Yaron asked me to review draft-ietf-ipsecme-ipsec-ha on 2010-06-01.
Here are my comments most of which are about clarifying text (so that
readers who didn't participate in the WG discussions can understand
this unambiguously), plus a couple of nits.
Yoav, could you post a new version that addresses my comments before
we start IETF Last Call?
#1) Should this I-D have been called "IPsec Cluter Problem Statement"
to more closely align with the charter? The header also?
#2) The abstract needs to be clearer and more closely follow what's in
the charter (I think the document does, but the abstract doesn't state
it clearly). It states:
This document describes a requirement from IKE and IPsec to allow for
more scalable and available deployments for VPNs. It defines
terminology for high availability and load sharing clusters
implementing IKE and IPsec, and describes gaps in the existing
standards.
Is this a requirement "from" or "for" IKE/IPsec? I think it's
supposed to be for.
It's missing the "problem statement" text from the charter. How about
the following suggested text:
This document defines a set of terminology, a problem statement, and
set of requirements for clusters implementing IKE and IPsec. It also
describes gaps in the existing standards that need to be filled in
order to allow peers to interoperate with clusters from different
vendors. An agreed terminology, problem statement, and requirements
will allow the IPSECME WG to consider development of IPsec/IKEv2
mechanisms to simplify cluster implementations.
#3) I'd like to see "cluster" introduced in the 2nd paragraph of
Section 1. It kind of jumps out in the 3rd para.
by using more than one physical gateway to either share the load
or back each other up (i.e., using a cluster).
^^^^^^^^^^^^^^^^^^^^^^^
#4) Section 1: r/organizations's/organization's
#5) Section 2: In section 1, it specifically mentions that the
gateways are physically separate. Should this also be worked in to
the definition of cluster in section 2:
"Cluster" is a set of two or more physically separated 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.
#6) Section 2: Should this I-D explain or point (informatively) to how
Availability is computed?
#7) Section 2: HS Cluster (there might only be one other): r/whereas
the others are/whereas the other(s) are
#8) Section 2: LS Cluster: Can we replace: "and we don't want to even
imply that this is a requirement" with "and this is not a requirement"?
#9) Section 2: Failover (add ,): r/In a load sharing cluster/In a load
sharing cluster,
#10) Section 2: Loose Cluster: Is it that one address gets allocated
to more than one member at failover, just one other, or can both
happen? r/In some cases, members IP addresses may be allocated to
other members at failover./In some cases, member's IP address(es) may
be allocated to another member or members at failover.
#11) Section 3.2: Spell out first instance of SAD (it's not in the RFC
editor's expansion
list:http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).
#12) Section 3.2 (last paragraph): The definition of High Availability
states that it's not a configuration type, but in the following it
sure does sound like it: "A naive implementation of a high
availability cluster would have no synchronized state, and a failover
would produce an effect similar to that of a rebooted gateway".
Because all of the clusters in this document offer high availability
can you just strike "high availability" from the sentence?
#13) Section 3.3: This section needs to be rephrased as a problem
statement not a solution. If the solution presented is a MUST
requirement, then I'd like to see that stated clearly with a "MUST".
#14) Assuming the sections 3.4 and 3.5 are about IPsec SA: r/SA/IPsec SA
#15) Section 3.4-9: I'd like to see clear requirements language about
what the mechanism(s) MUST/SHOULD/MAY support.
#16) Section 3.4: Shouldn't the 'must not' be "MUST NOT"?
#17) Section 3.5 (knowing people will want to verify this statement):
Please provide a pointer to where this is: This is allowed by the
standards, because replay counter verification is an optional feature.
i.e., see section x of [RFCXYZ].
#18) Section 3.6: All the clusters are highly available: r/a high
availability cluster/a cluster
#19) Section 3.7, spell out first instance of HA and add it to the
definition in Section 2.
#20) Section 3.7: what's a "commodity load balancer"?
#21) Section 3.7 to make the two category sentence work, r/The other
way, is to duplicate the child SAs, and have a pair of IPsec SAs for
each active member./The second is the "duplicate" category, where the
child SA is duplicated for each pair of IPsec SAs for each active member.
#22) Shouldn't the 'must never' be 'MUST NOT'?
spt
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
