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-cl-edge-behaviour-08 Reviewer: Elwyn Davies Review Date: 10 June 2011 IETF LC End Date: 10 June 2011 IESG Telechat date: (if known) - Summary: In my opinion, there are a number of areas that need significant work and at least one open issue (the stability question from s3.3.1) that needs to be addressed before this document is ready for the IESG. Major issues: The draft contains partial definitions of two control protocols (egress -> decision point; decision point -> ingress). It does not make it clear whether the reader is expected to get full definitions of these protocols here or whether there will be another document that specifies these protocols completely. As is stands one could build the protocols and pretty much guarantee that they would not be interoperable with other implementations since message formats are not included although high level specs are. The document needs to be much clearer about what is expected to happen here. Use of EXP codepoint: My understanding of what is said in RFC 5696 is that EXP is supposed to be left for other (non=PCN) systems to use. This draft uses it. Is this sensible? Is this whole draft experimental really? s3.3.1: > [CL-specific] The outcome of the comparison is not very sensitive > to the value of the CLE-limit in practice, because when threshold- > marking occurs it tends to persist long enough that threshold- > marked traffic becomes a large proportion of the received traffic > in a given interval. This statement worries me. It sounds like a characteristic of an unstable system. If the value is that non-critical why are we bothering? Minor issues: s1.1: definition of PCN-Traffic etc: > The same network will carry traffic of other Diffserv BAs. Just to be sure: Does this or does this not imply that *all* traffic in a PCN network must have a non-empty DSCP marking, i.e. that *all* traffic must be attached to some specific Diffserv BA? This should be clarified whichever is true. s1.1: T-fail: I notice from s3.1 that PCN-ingress nodes also have to make reports on request. Should T-fail or some other timer apply to non-return of info from ingress points? What would a (probably non-colocated) decision point do if it lost contact with the ingress? s2/s3.2.1: The use of PM and EXP codepoints for ThM and ETM appear to be reversed in these two sections!! Which way round is intended? s3.2.1/s3.2.2: Neither section mentions T-meas but I assume that this is supposed to be (either or both) the sampling period in the egress node or the period between reports. It is unclear if they are allowed to be different and if they are which one is T-meas. However s3.2.3 appears to imply that T-meas is probably the time between reports. This all needs to be much clearer. s3.2.1/3.2.2: In s3.2.2, para 2: > If so configured (e.g., because multipath routing is > being used, as explained in the previous section), the PCN-egress- > node MUST also report the set of flow identifiers of PCN-flows for > which excess-traffic-marking was observed in the most recent > measurement interval. This is a requirement for a protocol that you may or may not be defining. Confusing. s3.2.3/s3.2.2: The first paragraph of s3.2.3 suggests that the report from an egress may not always contain the calculated value of the CLE, but s3.2.2 has a MUST for the report to contain this value. Consistency!!! s6: The potential introduction of a centralized decision point appears to provide additional attack points beyond the architecture in RFC 5559. It appears to me that the requests for information about specific flows to the ingress are ighly vulnerable as they (probably) contain all the information needed to craft a DoS attack on the flow. Nits/editorial comments: General: Consistency of naming for timing paramters t-meas/T-meas, etc. s1.1: I think it would be worth reproducing the CL-specific definitions: PCN-threshold-rate and threshold-marked since they are specific. s1.1: > Congestion level estimate (CLE) > A value derived from the measurement of PCN-packets received at a > PCN-egress-node for a given ingress-egress-aggregate, representing > the ratio of marked to total PCN-traffic (measured in octets) ^^^^^ ^^^^^^^^^^^^^^^^^^ > received over a short period. The ratio is (hopefully) dimensionless. Maybe '(each measured in octets)' ? s2: > the PCN-domain satisfies the conditions specified in [RFC5696]; This may be a bit pedantic but I am not sure that RFC 5696 actually sets out conditions for the domain. It sets out rules for encoding markings and allowed transitions. Maybe s/conditions/packet markings and allowed transitions/. s3.1, para 1 and several other instances: s/collocated/co(-)located/ s3.2.1, para 5: s/statistical variance/statistical variation/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf