[Gen-art] Review: draft-ietf-bmwg-protection-meth-12.txt
"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 12 November 2012 16:22 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C421F84CD; Mon, 12 Nov 2012 08:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQwogQadDJ1i; Mon, 12 Nov 2012 08:22:34 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 119F021F8529; Mon, 12 Nov 2012 08:22:34 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 858AD558968; Mon, 12 Nov 2012 08:22:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 145A41C08E9; Mon, 12 Nov 2012 08:22:32 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-71-161-52-236.clppva.btas.verizon.net [71.161.52.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CBA4A1C08F4; Mon, 12 Nov 2012 08:22:30 -0800 (PST)
Message-ID: <50A1223F.10902@joelhalpern.com>
Date: Mon, 12 Nov 2012 11:22:23 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: gen-art@ietf.org
References: <4F5973CE.309@nostrum.com>
In-Reply-To: <4F5973CE.309@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Ron Bonica <rbonica@juniper.net>, draft-ietf-bmwg-protection-meth.all@tools.ietf.org, bmwg@ietf.org, Al Morton <acmorton@att.com>
Subject: [Gen-art] Review: draft-ietf-bmwg-protection-meth-12.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2012 16:22:36 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-bmwg-protection-meth-12.txt Methodology for benchmarking MPLS protection mechanisms Reviewer: Joel M. Halpern Review Date: 12-November-2012 IETF LC End Date: 20-March-2012 IESG Telechat date: 15-November-2012 Summary: This document is almost ready for publication as an Informational RFC. This reviewer notes with thanks that a number of his concerns from the March review have been well-addressed. Major Comments: Section 5.7 is still internally inconsistent. It says that "It is suggested that there be three or more traffic streams..." in the first paragraph. The second paragraph then begins "At least 16 flows should be used, ..." I have compared the definitions in RFC 4689, and I can not see how 3 streams (A group of packets treated as a single entity by the traffic receiver) can be 16 flows (one or more packets sharing a common intended pair of ingress and egress interfaces.) I suspect that the issue is what traffic receiver is intended. Is the intent that there be at least 3 LSPs with 16 or more flows running through them? Minor Comments: In section 5.1 "some" failure events are listed. It is unclear whether this list is the ones to be tested for, or just "some" events. I think it is intended to be comprehensive, so why "some". I presume that the use of the term Layer2 VC in section 6 is intended to refer to a pt-to-pt layer2 VPN component. Is there an existing document where that term is used that way? Could it be referenced? For that matter, since the number of labels is the same in the Layer3 cases and the Layer2 cases, could the Layer2 cases be omitted without loss of generality?
- [Gen-art] A *new* batch of IETF LC reviews - 2012… A. Jean Mahoney
- [Gen-art] Review: draft-ietf-bmwg-protection-meth… Joel M. Halpern
- Re: [Gen-art] Review: draft-ietf-bmwg-protection-… Rajiv Papneja
- [Gen-art] Review: draft-ietf-bmwg-protection-meth… Joel M. Halpern