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

"David Harrington" <ietfdbh@comcast.net> Fri, 13 January 2012 23:30 UTC

Return-Path: <ietfdbh@comcast.net>
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 26AF121F84D3 for <gen-art@ietfa.amsl.com>; Fri, 13 Jan 2012 15:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.425
X-Spam-Level:
X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, 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 8-Br6TSf5C4a for <gen-art@ietfa.amsl.com>; Fri, 13 Jan 2012 15:30:07 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0678A21F84CD for <gen-art@ietf.org>; Fri, 13 Jan 2012 15:30:06 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id M02s1i0041uE5Es54BW7ud; Fri, 13 Jan 2012 23:30:07 +0000
Received: from davidPC ([71.233.85.150]) by omta16.westchester.pa.mail.comcast.net with comcast id MBW61i00R3Ecudz3cBW6Hd; Fri, 13 Jan 2012 23:30:07 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: "'Tom Taylor'" <tom111.taylor@bell.net>, "'Joel M. Halpern'" <jmh@joelhalpern.com>
References: <CAHBDyN6PN-vp9wXo6fF8G4VfODXjkfbWBaJN8EPopeWfOg9PmQ@mail.gmail.com> <4EFF838D.5020704@joelhalpern.com> <BLU0-SMTP18EE1E01EAA97CC44A44FFD8900@phx.gbl>
In-Reply-To: <BLU0-SMTP18EE1E01EAA97CC44A44FFD8900@phx.gbl>
Date: Fri, 13 Jan 2012 18:30:01 -0500
Message-ID: <CF9796FD9102439E9BA368815AA8C722@davidPC>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AczIvmdXLiFoJHyZTomqykSk1jqZoAJjIYMQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609
Cc: gen-art@ietf.org, draft-ietf-pcn-sm-edge-behaviour@tools.ietf.org, 'Steven Blake' <slblake@petri-meat.com>
Subject: Re: [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: Fri, 13 Jan 2012 23:30:08 -0000

Hi Tom,

If you change this to Experimental, then the Intro should have a
discussion of the experiment, including some guidance about how to
judge success. The current IESG has been a stickler on that point.

dbh 

> -----Original Message-----
> From: Tom Taylor [mailto:tom111.taylor@bell.net] 
> Sent: Sunday, January 01, 2012 2:49 PM
> To: Joel M. Halpern
> Cc: Mary Barnes; gen-art@ietf.org; Steven Blake; David 
> Harrington; draft-ietf-pcn-sm-edge-behaviour@tools.ietf.org
> Subject: Re: [Gen-art] Review: draft-ietf-pcn-sm-edge-behaviour-08
> 
> Thanks for the review, Joel. Comments below, marked with [PTT].
> 
> On 31/12/2011 4:50 PM, Joel M. Halpern wrote:
> > 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.
> 
> [PTT] OK, we've wobbled on this one, but we can follow your 
> suggestion.
> >
> > 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.
> 
> [PTT] You are right that RFC 5696 isn't relevant. It's such a 
> long time 
> since that text was written that I can't recall what the 
> intention was. 
> My inclination at the moment is simply to delete the bullet.
> >
> > 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.
> 
> [PTT] I'm not sure what the issue is here. As I understand 
> it, operators 
> don't assign packets randomly to a given path in the presence of 
> alternatives -- they choose one based on values in the packet
header. 
> The basic intent is that packets of a given microflow all follow the

> same path, to prevent unnecessary reordering and minimize jitter.
The 
> implication is that filters can be defined at the ingress nodes to 
> identify the packets in a given ingress-egress-aggregate 
> (i.e. flowing 
> from a specific ingress node to a specific egress node) based 
> on their 
> header contents. The filters to do the same job at egress nodes are
a 
> different problem, but they are not affected by ECMP.
> >
> > 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.)
> 
> [PTT] We aren't driving the excess rate to zero, but to a 
> value equal to
> something less than (U - 1)/U. (The "something less" is because of 
> packet dropping at interior nodes.) The assumption is that (U 
> - 1)/U is 
> greater than CLE-limit. Conceptually, PCN uses two 
> thresholds. When the 
> CLE is below the first threshold, new flows are admitted. Above that

> threshold, they are blocked. When the CLE is above the second 
> threshold, 
> flows are terminated to bring them down to that threshold. In the SM

> mode of operation, the first threshold is specified directly on a 
> per-link basis by the value CLE-limit. The second threshold 
> is specified 
> by the same value (U - 1)/U for all links. With the CL mode 
> of operation 
> the second threshold is also specified directly for each link.
> >
> >
> > Nits/editorial comments:
> >
> >
>