Hi Sean. I have just submitted version -05 which addresses most (but not all) of your comments. Here's a list of the exceptions (hope I didn't miss any)
#2. I've worded the abstract a little differently. Main difference is adding to "gaps in existing standards" the words "and their implementation". Some things (like tolerating skips in replay counters and multiple parallel SAs) are allowed by the RFC even now, but some vendors may perceive them as "weird" and drop the tunnels. Yes, we've had this happen with real vendors. This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation 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. #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with this. The first, is that this document is a problem statement, and intended to be INFORMATIONAL. No gateway is ever going to be said to "implement" this document. As such, I don't think it should mandate any behaviors. Some behaviors are suggested as solutions, for example "replay counter must not repeat" ==> "gateway can synchronize occasionally, and skip 10,000 numbers at failover". The charter does not allow us at this point to mandate that newly-active gateways skip 10,000 numbers. We only say this, because it is one way to solve the problem, which some vendors have already done, and other gateways should be ready for this to happen. When it comes to creating a standards-track document, we might suggest this to cluster implementers, and more important, we may mandate that all conforming IPsec implementers (whether their gateways cluster or not) MUST accept such replay counter jumps. So I left most of sections 3.4-9 without RFC 2119 language. As an exception to this rule, where the behavior is already mandated by older RFCs (4301 and/or 4306), I did capitalize the requirement language (so "replay counter must never repeat" --> "replay counter MUST NOT repeat") Yoav On Jun 8, 2010, at 2:23 PM, Sean Turner wrote: > 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 > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
