[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?