Subject: [PCN] comment on revised cl-edge

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Dec 2010 15:19:26 -0500

Hi,

So I started this email thinking i had a few minor comments. But as i
progressed, I realized that wasn't going to be true. As I said
earlier,
You are only at square one of the publication process. The documents
are in AD Evaluation; they have not gone to the IESG yet. We are doing
all this in the first round. Hopefully, this all this work will
smooth the way through the IESG Evaluation. ;-) 

Unfortunately, as I get into these document more, I am thinking there
are a few things that will not just be minor comments.

Don't get me wrong. I think these documents are well-written, fairly
easy to understand even for a novice, and important. We need a little
polish, and attention to some details that have not been addressed
yet.

1) in 3.5, you say 
      "At the time of writing,  
       that transport protocol has not yet been specified.  This  
       specification therefore requires that any transport protocol  
       specification for carrying PCN reports MUST specify an
appropriate  
       default value for T-maxsuppress."
Well, as an IESG member, that certainly makes me think that maybe we
should get that (one) protocol defined before advancing the spec. 
and since this specification THEREFORE requires ...
makes me wonder what happens when that transport IS defined; does that
mean this spec no longer requires ...?
I suggest:
      "Any transport protocol  
       specification for carrying PCN reports MUST specify an
appropriate  
       default value for T-maxsuppress."

however, how does one know what "appropriate" means? I think this
needs to be explained further.

The next paragraph talks about t-fail as a function of T-maxsuppress.
So if they use an inappropriate value for T-maxsuppress, that gets
cascaded into t-fail as well.

The text says t-maxsuppress is only active when report suppression is
enabled. If t-fail is a function of t-maxsuppress, does that mean
t-fail is also only active when report suppression is enabled? If
t-fail is active whether suppression is enabled or not, then maybe you
would do better to discuss t-fail first and then discuss
t-maxsuppression as a function of t-fail. 

Either way, I think we need to provide more concrete guidance than
these paragraphs offer.

2) in 4., I think I'd change "MUST send" to "sends"

3) in 5.1, is "too many flows" excessive terminations? It's awfully
vague.

4) in 5.2.1, "MUST block ... Alternatively ..." - it cannot be both
MUST and alternatively. How about "MUST be prevented from entering the
domain, such as by blocking or tunneling, ..." and then discuss those
approaches.

5) 5.2 flowspec is used before being defined.

6) 5.2.2 section title - expand PHB

7) It's been a while since I've dealt with diffserv. The "as a result"
conclusion in 5.2.2 is not obvious to me (and is unlikely to be
obvious to some members of IESG). The first sentence says "are
metering and marking rather then scheduling", which is also a little
non-obvious why that distinction is being made. I think the first two
sentences might be written with a little more explanation of the
nature of configuration needed for metering and marking behaviors. And
there is no justification for why the WG suggests admission control
for these particular classes. (and as a matter of style, I think it is
usually inappropriate to talk about the WG; just make the
recommendation - It is RECOMMENDED that admission control be used for
the following classes.)

8) in 5.3, the design requirement for PCN was that ... yeah, and what
is the design requirement now? Hmmm, if the requirement was 1..3
seconds, and we now do it in, say, 0.5 seconds, do we meet the
requirement? - our number is not in the range of 1..3. or is the
design requirement 3 seconds or less?

9) in 5.4, we say "see section 2"; but section 2 says "see RFC 5670";
why such an indirect route?
and under parameters at the interior node, we also point to section 2
for the same meters. maybe we don't need the references for these
meters since references are provided in section 2, where we say we
will use these terms throughout the document.

10) in 5.5,
	Assumed that a specific portion of link capacity has been
reserved  
 
	Assumed that the Decision Point receives requests  
       for admission of PCN-flows before the packets in the PCN-flows

       arrive.  This is not a critical assumption, but in its absence,

       packets will be dropped by the PCN-ingress-node until it
obtains the  
       admission decision from the Decision Point. 

how about Assumptions:
1) a specific portion of link capacity has been reserved for
PCN-traffic.
2) the Decision Point receives requests  
       for admission of PCN-flows before the packets in the PCN-flows

       arrive, and
       packets will not be dropped by the PCN-ingress-node until it
obtains the  
       admission decision from the Decision Point.

is this "will not" really a MUST NOT? or SHOULD NOT?

11) in 6, does ECN ever play into security considerations? does
reusing ecn bits then have a potential impact on security? 
- What about tunneling ECN-enabled traffic? Preventing entry into the
domain is a CL-edge requirement, right? Therefore, this document does
introduce new considerations for security, such as those mentioned in
RFC6040.
- what about blocking ecn-enabled traffic? ditto.

from RFC6040:
   Ensuring congestion
   markings are not lost is itself an aspect of security, because if
we
   allowed congestion notification to be lost, any attempt to enforce
a
   response to congestion would be much harder.

so I think this section needs a little more work.

12) I think this document might need an operational considerations
section that talks about the potential need to deploy ECN-tunneling
support in networks that use ECN and cl-edge metering/marking. plus a
discussion of the effect blocking of ECN might have for an operator.

There may be other operational considerations involved that will delay
IESG approval. 

The OPS area developed a set of guidelines for operational and
management considerations (RFC5706), and the OPS ADs are checking for
these considerations in documents coming before the IESG. Have we
checked to see if we would pass such a check? 

The OPS-dir has developed a checklist of things for reviewers to look
for when reviewing documents. Would we pass their checklist? (FYI, I
am pushing for similar guidelines and a checklist for transport issues
because not all authors bother to consider and document issues of
congestion control, ECN/PCN, timer values, etc.)

13) I think this document needs a management considerations section to
discuss how the operator can tell what is happening to the traffic in
their network. If you're dropping, tunneling, metering, etc. how is
that made visible to the operator? Does the Diffserv-MIB have that
information? 

MUST an implementer of CL-edge metering be sure that the CL metering
is reflected in the Diffserv-MIB's diffServMeterTable? where do you
say that?

How are the drops counted? are blocked ecn packets counted as drops?
in which statistic?

as an operator, where should I look to find the t-meas,
t-maxsuppresssion, and t-fail values in effect? 

the parameters required differ depending on where in the system you
are, as described in 5.4. How are these parameters made accessible to
the operator? Do each of these parameters have a default value? Are
there different compliance rules for a PCN-ingress-node implementation
than for a PCN-egress-node, than for an interior versus border node?
as an operator, how can I tell whether a decision point is using the
right mapping between IEA and corrseponding ingress and egress nodes?

How do you expect the confugraiton to be done? will you use an IETf
standard configuration protocol like netconf? proprietary CLIs? is
there a requirement that these be consistent across vendors? If there
are implied requirements about the responsibilities of border vs
interior nodes, and the border routers from vendor A use different
approaches to configuration than interior routers from vendor B, how
can you be sure they will work together properly? 

What are the ranges of acceptable values for parameters like t-fail
and t-meas? do these need to be consistent across implementations, or
are they only important within an implementation? What range does an
interior node need to support (conservative in what you send), and
what range of values does a decision point need to support (liberal in
what you receive)? What if two implementers support non-overlaping
ranges for these two ends of the communication?

I think this needs work.

(and don't tell me "it's not in the charter" - it is an IESG
expectation that protocols be operational and manageable and secure,
among other things. I can show you many IETF charters that never
mention congestion control, but specifications are still required to
talk about congestion control if use of the protocol could cause
congestion.)

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)