Subject: [PCN] AD Review: draft-ietf-pcn-cl-edge-behaviour-07

From: "David Harrington" <[email-masked]>
Date: Mon, 6 Dec 2010 15:56:03 -0500

Hi,

Because this document has so much common text with the SM document,
almost all the AD Review comments for the SM document apply to CL as
well. Please incorporate those comments into this review.

A few comments came to mind after sending the SM review, that apply to
both; I added parenthesis to indictae it applies to both).

1) in section 2, reference is made to the "possible extension"
[ID.PCN3in1].
I recommend against referencing "possible extension" documents. 

2) "These allowable transitions are specified here" - usually
specified implies a normative specification. I suggest rewording with
less normative-like wording.

3) in 3.2.3, the calculation for CLE uses either the latest or the
previous interval in its caculations. Niether SM nor CL explains why
it is acceptable to use either interval. Is this explained somewhere?
How does this affect interoperability? (also applies to SM)

4) in 3.3.2, the DP MUST request an estimate of pcn-sent-rate; is
there a specific protocol that must/should be used to do this
(assuming they are not co-located)? If not, how is this
request/response done in a vendor-interoperable manner?

5) in 3.3.2, last paragraph, the list must be ETM-marked flows, right?
It doesn't say that.

6) in 3.3., an alarm should be raised to management. is there are
standardized approach to raising the alarm? If not, how does this
affect interoperability. Most notably, if two nodes form different
vendors raise an alarm using different protocols, how will the
management system correlate the alarms? If two implementations use
SNMP to raise the alarms, should they use consistent OIDs to identify
the problem? or consistent syslog SDEs? or consistent ipfix IEs?
Should the WG standardize the information models, and possibly data
models and protocols, for reporting such alarms?
 
7) in 5.2, it is asserted that [ID.PCN3in1] specifies the behavior;
but 2.2 mentions this as a "possible extension". If PCN3in1 is not
STDS track, then i think this text in 5.2 could be problematic. But I
suspect that 3086 expects a stable specification.

I have not worked with the 3086 template before. Is a reference to a
number of RFCs, without any discussion of their details really
sufficient? It doesn't sounce like that meets the description from
3086:

   This section specifies the rules or guidelines to create this PDB,
   each distinguished with "may", "must" and "should." The technical
   specification must list the classification and traffic conditioning
   required (if any) and the PHB (or PHBs) to be used with any
   additional requirements on their configuration beyond that
contained
   in RFCs.  Classification can reflect the results of an admission
   control process.  Traffic conditioning may include marking, traffic
   shaping, and policing.  A Service Provisioning Policy might be used
   to describe the technical specification of a particular PDB.

8) in 5.7, the reader is referred to "the applicable specifications";
can we identify the applicable specifications?

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

---

From: Tom Taylor <[email-masked]>
Date: Tue, 7 Dec 2010 09:56:07 -0500

This one has some meatier issues. Responses below.

> I recommend against referencing "possible extension" documents.

[PTT] Would it be OK to call it an example?
> less normative-like wording.

[PTT] The point, of course, is not to specify the same thing in two 
places. However, it's probably legitimate to say that an extension 
suitable for the CL edge behaviour MUST conform to the following 
transitions ...
> How does this affect interoperability? (also applies to SM)

[PTT] This is meant to be an inclusive OR, that is, the condition 2 MUST 
be satisfied for both intervals. I'll review wording.
> request/response done in a vendor-interoperable manner?

[PTT] Protocol development is outside the PCN charter. We do have a 
signalling requirements document in progress. I'll also mention that I 
was about to revive draft-fortune-dime-pcn-collection as one proposal 
for a PCN data collection protocol (using Diameter as an accounting 
application).
> 5) in 3.3.2, last paragraph, the list must be ETM-marked flows, right?
[PTT] I can mention it. 3.2.2 specifies that only ETM-marked flows are 
reported.

> models and protocols, for reporting such alarms?

[PTT] To start with the last point, I can't see the WG specifying 
management protocols specifically to manage PCN -- this would be the 
tail wagging the dog. PCN is just one small part of managing a network, 
and I would think the operator would already have deployed their 
preferred tools. The best we could do is to ensure interoperability for 
each of the likely alternatives.
> suspect that 3086 expects a stable specification.
[PTT] [ID.PCN3in1] is currently Experimental. I can't remember if the 
plan is to reclassify it as Standards Track now that RFC 6040 has been 
published as Proposed Standard. Perhaps Toby or Bob could comment.

>     to describe the technical specification of a particular PDB.

[PTT] I'll look for an example to follow.
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 13 Dec 2010 12:31:49 -0500

Here is the proposed response to your second review E-mail. Again, 
everyone is invited to comment.

> well. Please incorporate those comments into this review.

[PTT response] OK

======================
> I recommend against referencing "possible extension" documents.

[PTT response] I propose to rewrite Section 2. The essence of the 
changes is to base the encoding entirely on RFC 5696, while leaving room 
for an unidentified successor document. Mention of I-D.PCN3in1 will also 
be dropped from the PDB template (see below).

Here is the proposed text for the CL document:

"2. [CL-Specific] Assumed Core Network Behaviour for CL	
				
This section describes the assumed behaviour for nodes of the PCN-domain 
when acting in their role as PCN-interior-nodes. The CL mode	
of operation assumes that:	
				
   o PCN-interior-nodes perform both threshold-marking and 
excess-traffic-marking of packets, according to the rules 
specified in		[RFC5670];	
				
   o excess-traffic-marking of packets uses the PCN-Marked (PM) 
codepoint defined in [RFC5696];			
				
   o threshold-marking of packets uses the EXP codepoint defined in 
[RFC5696];	
				
   o the PCN-domain satisfies the conditions specified in [RFC5696];	
				
   o on each link the reference rate for the threshold-meter is 
configured to be equal to the PCN-admissible-rate for the link;		
				
   o on each link the reference rate for the excess traffic meter is 
configured to be equal to the PCN-supportable-rate for the link;	
				
   o the set of valid codepoint transitions is as shown in Section 4.2 
of [RFC5696]."	

As a follow-up, it is proposed to add clauses indicating the packet 
marking in section 3.2.1 for the different rates. The text would become:

"The PCN-egress-node MUST meter received PCN-traffic in order to derive 
periodically the following rates for each ingress-egress-aggregate 
passing through it:	
				
   o NM-rate: octets per second of PCN-traffic in PCN-packets that are 
not-marked (i.e., marked with the NM codepoint);			
				
   o [CL-specific] ThM-rate: octets per second of PCN-traffic in 
PCN-packets that are threshold-marked (i.e., marked with the PM	 
codepoint);				
				
   o [CL-specific] ETM-rate: octets per second of PCN-traffic in 
PCN-packets that are excess-traffic-marked (i.e., marked with the EXP 
codepoint).

Similar changes would be made to the SM document.

======================
	
> less normative-like wording.

[PTT response] Replaced by reference to the normative document. See above.

======================
> How does this affect interoperability? (also applies to SM)
[PTT response] Will reword to make it clear that both conditions must be 
tested.

======================

> request/response done in a vendor-interoperable manner?

[PTT response] Answered in previous note. Protocol specification is 
still to be done but is explicitly outside the PCN WG charter.
> 5) in 3.3.2, last paragraph, the list must be ETM-marked flows, right?

[PTT response] Will add.

======================
> models and protocols, for reporting such alarms?

[PTT response] This is a topic for another document. The work item seems 
to be missing from the WG charter.

======================
> suspect that 3086 expects a stable specification.

[PTT response] Reference to that I-D will be dropped.

======================

>     to describe the technical specification of a particular PDB.

[PTT response] The only use of the template I could readily find as a 
model was RFC 3662. Proposed to use the following text (common to both 
CL and SM):

"5.2 Technical Specification

5.2.1 Classification and Traffic Conditioning
		
This section paraphrases the applicable portions of Sections 3.6 and 4.2 
of [RFC5559].
		
Packets at the ingress to the domain are classified as either PCN
or non-PCN. Non-PCN packets may share the network with PCN packets
within the domain. Because the encoding specified in [RFC5696] and used 
in this document requires the use of the ECN fields, PCN-ingress-nodes 
MUST block ECN-capable traffic that uses the same DSCP as PCN from 
entering the PCN-domain directly.  "Blocking" means it is dropped or
downgraded to a lower-priority behaviour aggregate. Alternatively
such traffic MAY be tunnelled through the PCN-domain.
			
PCN packets are further classified as belonging or not belonging to
an admitted flow. PCN packets not belonging to an admitted flow are
dropped. (This assumes that requests for flow admission are signalled
in advance of the arrival of the flows themselves.) Packets belonging
to an admitted flow are policed to ensure that they adhere to the agreed
rate or flowspec.
		
5.2.2 PHB Configuration
		
The PCN SM and CL boundary node behaviours are metering and marking 
behaviours rather than scheduling behaviours. As a result, they are not 
tied to the selection of a specific DSCP value. The PCN working group 
suggests using admission control for the following service classes 
(defined in [RFC4594]):

    o  Telephony (EF)

    o  Real-time interactive (CS4)

    o  Broadcast Video (CS3)

    o  Multimedia Conferencing (AF4)

For a fuller discussion, see Section A.1 of Appendix A of [RFC5696]."

======================

> can we identify the applicable specifications?

[PTT response] That will be RFCs 5559 as paraphrased above, plus RFC 
5696. Will fix, with section references.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Dec 2010 08:45:56 -0500

This is a repeat of yesterday's mail with a new subject line, since no 
one seems to have noticed it.

[PTT response] OK

======================

				

				

				

				

======================

======================

======================

[PTT response] Will add.

======================

======================

======================

		

		
5.2.2 PHB Configuration

    o  Telephony (EF)

    o  Broadcast Video (CS3)

======================