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

["David Harrington" <[e-mail]>]

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:[e-mail]] 
> Sent: Sunday, January 01, 2012 2:49 PM
> To: Joel M. Halpern
> Cc: Mary Barnes; [e-mail]; Steven Blake; David 
> Harrington; [e-mail]
> 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:
> >
> >
>