[Gen-art] Review: draft-ietf-pcn-sm-edge-behaviour-08

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 31 December 2011 21:50 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 4B3B421F84B8 for <gen-art@ietfa.amsl.com>; Sat, 31 Dec 2011 13:50:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03-o2b-7xQmv for <gen-art@ietfa.amsl.com>; Sat, 31 Dec 2011 13:50:13 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D8DFD21F8476 for <gen-art@ietf.org>; Sat, 31 Dec 2011 13:50:13 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id BDAB7CAEDC for <gen-art@ietf.org>; Sat, 31 Dec 2011 13:50:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 18FD01C0879; Sat, 31 Dec 2011 13:50:12 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 85BF91C0859; Sat, 31 Dec 2011 13:49:59 -0800 (PST)
Message-ID: <4EFF838D.5020704@joelhalpern.com>
Date: Sat, 31 Dec 2011 16:50:05 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <CAHBDyN6PN-vp9wXo6fF8G4VfODXjkfbWBaJN8EPopeWfOg9PmQ@mail.gmail.com>
In-Reply-To: <CAHBDyN6PN-vp9wXo6fF8G4VfODXjkfbWBaJN8EPopeWfOg9PmQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, David Harrington <ietfdbh@comcast.net>, draft-ietf-pcn-sm-edge-behaviour@tools.ietf.org, Steven Blake <slblake@petri-meat.com>
Subject: [Gen-art] Review: draft-ietf-pcn-sm-edge-behaviour-08
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: Sat, 31 Dec 2011 21:50:18 -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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pcn-sm-edge-behaviour-08
     PCN Boundary Node Behaviour for the Single Marking (SM) Mode of
                                Operation
Reviewer: Joel M. Halpern
Review Date: 31-Dec-2011
IETF LC End Date: 13-Jan-2012
IESG Telechat date: N/A

Summary: This documents is almost ready for publication as an 
Informational RFC.

Question:  Given that the document defines a complex set of behaviors, 
which are mandatory for compliant systems, it seems that this ought to 
be Experimental rather than Informational.  It describes something that 
could, in theory, later become standards track.

Major issues:
     Section 2 on Assumed Core Network Behavior for SM, in the third 
bullet, states that the PCN-domain satisfies the conditions specified in 
RFC 5696.  Unfortunately, look at RFC 5696 I can not tell what 
conditions these are.  Is this supposed to be a reference to RFC 5559 
instead?  No matter which document it is referencing, please be more 
specific about which section / conditions are meant.

     It would have been helpful if the early part of the document 
indicated that the edge node information about how to determine 
ingress-egress-aggregates was described in section 5.
     In conjunction with that, section 5.1.2, third paragraph, seems to 
describe an option which does not seem to quite work.  After describing 
how to use tunneling, and how to work with signaling, the text refers to 
inferring the ingress-egress-aggregate from the routing information.  In 
the presence of multiple equal-cost domain exits (which does occur in 
reality), the routing table is not sufficient information to make this 
determination.  Unless I am very confused (which does happen) this seems 
to be a serious hole in the specification.

Minor issues:
     Section 3.3.1 states that the "block" decision occurs when the CLE 
(excess over total) rate exceeds the configured limit.  However, section 
3.3.2 states that the decision node must take further stapes if the 
excess rate is non-zero in further reports.  Is this inconsistency 
deliberate?  If so, please explain.  If not, please fix.  (If it is 
important to drive the excess rate to 0, then why is action only 
initiated when the ratio is above a configured value, rather than any 
non-zero value?  I can conceive of various reasons.  But none are stated.)


Nits/editorial comments: