Benchmarking Terminology for Protection Performance
Note: This ballot was opened for revision 09 and is now closed.
(Ron Bonica) Yes
(Dan Romascanu) Yes
Comment (2010-06-17 for -)
It looks to me that 'Benchmarking Terminology for Performance of sub-IP layer Protection Mechanisms' would be a more apropriate name for this document.
(Jari Arkko) No Objection
(Stewart Bryant) No Objection
Comment (2010-06-16 for -)
I am not sure that RFC2119 language is appropriate here Figures 1 through 5 show models that MAY be used when benchmarking Sub-IP Protection mechanisms, which MUST use a Protection Switching System that consists of a minimum of two Protection-Switching Nodes, an Ingress Node known as the Headend Node and an Egress Node known as the Merge Node. Ideally the RFC2119 definition should appear before first use in the document The Protection Switching System MUST include either a Primary Path and Backup Path, as shown in Figures 1 through 4, or a Primary Node and Standby Node, as shown in Figure 5. I am not a mathematician, can an equation have a pluarity of sub-equations, or is a different mathematical construct needed? TBLM as shown in Equation 2: (Equation 2) (Equation 2a) TBLM Failover Time = Time(Failover) - Time(Failover Event) (Equation 2b) TBLM Reversion Time = Time(Reversion) - Time(Restoration) Same with Eq3
(Gonzalo Camarillo) No Objection
(Lars Eggert) (was Discuss) No Objection
> Benchmarking Terminology > for Protection Performance As stated in the abstract, Section 3.5 actually defines some tests. The title should reflect that this document is not only defining terminology. Section 3.1., paragraph 4: > b. Ri is a node which forwards data frames to R[i+1] over Link > Li[i+1] for all i, 1 layer. Since R1/L12 are defined in (a) and (c) defines Rn, you probably want to change 1
(Adrian Farrel) No Objection
Comment (2010-06-16 for -)
I have a huge raft of issues and concerns about this document. In the end I raised a COMMENT not a DISCUSS because I don't believe that the publication of this document as an Informational RFC without making the changes will be harmful. However, attending to these comments would, I believe significantly improve the value of your work. The responsible AD may decide that the comments need to be addressed. --- idnits (http://tools.ietf.org/tools/idnits/) throws up a number of issues. Although many of these are minor or editorial, it would have made the document easier to read had you fixed them. I think that some of the boilerplate issues are more significant and that the I-D cannot be accepted unless a new revision with the correct boilerplate is submitted. The document writeup says: (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? There are a few errors in the nits: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bmwg-protection-term-08.txt These can be corrected after AD-review, but there will be some work necessary to adopt the new boilerplate, update references, fix page lengths, etc. Clearly this did not happen, and I really think we need to push back on document shepherds to understand that the only acceptable answer to the question is "Yes, idnits passes cleanly". --- There is a significant different between the document title ("Benchmarking Terminology for Protection Performance") and the content of the document as explained in the Abstract and Introduction. Viz. This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. 1. The title should mention metrics 2. The title should indicate the scope is sub-IP --- The Introduction starts off with... Technologies that function at sub-IP layers can be enabled to provide further protection of IP traffic by providing the failure recovery at the sub-IP layers so that the outage is not observed at the IP-layer. This seems a reasonable statement, but isn't it in contradiction with the whole premise of this document as stated in the Abstract... The performance benchmarks are measured at the IP-Layer, avoiding dependence on specific sub-IP protection mechanisms. In other words, if the outage is not observed at the IP-layer, how will you measure the benchmarks at the IP-Layer? --- I would really have liked this work to be aligned with RFC 4427. That document sets out terminology for protection and restoration in GMPLS networks (i.e. sub-IP) and attempts to achieve alignment with ITU-T Recommendations G.808.1 and G.841. It is important to use identical rather than similar terms for protection and restoration techniques across the IETF when we are referring to sub-IP layers. Actually, I find the terminology rather woolly. For example, in Section 1 The Working Path is the Primary Path prior to the Failover Event and the Backup Path after the Failover Event. Yet in Section 3.1.3 The Primary Path is the Path that traffic traverses prior to a Failover Event. And it is difficult to read a document where the terms are used well in advance of their definitions. It might help if Section 3 was split with sections 3.1 through 3.4 presented as terminology, and sections 3.5 onwards as Test Considerations. The definition of "Restoration" in section 3.3.5 is unlike anything I have seen before and is very much at odds with the way the term is used in sub-IP networks. --- Figure 4 There is a spurious arrow head on the left-hand end of the arrow marked "IP-Layer Forwarding" --- Section 3.1.1 a. R1 is the ingress node and forwards IP packets, which input into DUT/SUT, to R2 as sub-IP frames over link L12. b. Ri is a node which forwards data frames to R[i+1] over Link Li[i+1] for all i, 1
(Russ Housley) No Objection
(Tim Polk) No Objection
Comment (2010-06-15 for -)
I suspect this is clear enough for its intended audience, but a more detailed description of the calculations in 3.6.1 and 3.6.3 would help novice readers. I couldn't quite sort out the equations. For example in 3.6.3 (TBM), are the following interpretations correct? (1) Time(Failover) = Timestamp on first unimpaired packet received at egress node after the backup path became the working (2) Time(Failover Event) = Timestamp on the last unimpaired packet received at egress node on the primary path before failure I was unable to construct similar statements for the TBLM in 3.6.1 at all. Nits: in section 3.1.1, there is a confusing mixture of notation, using parentheses and brackets interchangeably. The definition of path uses parentheses, as in "L(n-1)n", but the description of node in subitem b. uses brackets, as in "Li[i+1]". In 3.6.3 under discussion, the comma following "observation of unimpaired packets" should be a period.