Subject: [PCN] I-D Action:draft-ietf-pcn-signaling-requirements-01.txt

From: [email-masked]
Date: Tue, 19 Oct 2010 23:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain
	Author(s)       : G. Karagiannis, et al.
	Filename        : draft-ietf-pcn-signaling-requirements-01.txt
	Pages           : 10
	Date            : 2010-10-19

Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain. The 
overall PCN architecture is described in RFC 5559. This memo 
describes the requirements for the signaling applied within the PCN 
domain: PCN feedback is carried from the PCN-egress-node to the 
decision point and the decision point may demand for the measurement 
and delivery of the PCN rate sent at the PCN-ingress-node. The 
decision point may be either collocated with the PCN-ingress-node or 
a centralized node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 20 Oct 2010 06:59:48 +0000

Hi Steve, Hi Scott, Hi all

Based on the comments received up to now and based on the last versions
of:
draft-ietf-pcn-cl-edge-behaviour-07 and
draft-ietf-pcn-sm-edge-behaviour-04 we updated the signaling
requirements draft.

In my opinion we can start the WG Last Call for this draft!

Best regards,
Georgios

On 10/20/2010, "[email-masked]" <[email-masked]>
wrote:

>http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-01txt
>

---

From: Steven Blake <[email-masked]>
Date: Thu, 21 Oct 2010 10:28:52 -0400

> In my opinion we can start the WG Last Call for this draft!

Ok, thanks Georgios.

The WGLC for draft-ietf-pcn-signaling-requirements-01 starts today,
concluding Thursday, Nov. 4.  Please send comments to the pcn list.

Regards,

// Steve

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 11:14:24 +0100

Unfortunately the doc seems to need a lot of work to me. 

*	It repeats a lot of the edge behaviour docs. If i get it right, this doc is supposed to be *just* about the signalling (the requirements for signalling) - the edge node behaviour docs talk about the *content* that is signalled. To take just one example:
o	S2.2 starts by listing what the PCN-egress-node measures - but this doc should be about reports - reporting the info that's been measured (reference edge behaviour doc for details of what is measured)
o	The list anyway doesn't match the edge behaviour docs (CLE may or may not be calculated by PCN-egress-node)
*	There are some new security considerations that i don't agree with. See below. 
*	The terminology should consistently re-use what has already been defined in our RFCs and what is defined in the edge behaviour docs. See below. 
*	The sub-section headings of S2 & S3 should match. This might help S3 to be re-written more clearly. 
*	S3.3 is untrue. 3.2 & 2.3.6 are different [at least] 
*	S2.2: I don't think report suppression should be mentioned here as a compulsory feature. This is to do with specific signalling examples (CL, SM) and not a general feature required of all imaginable PCN edge signalling. Report suppression is a feature of the edge behaviour. At most this doc should say something like "A report may either be sent periodically, every time the PCN-egress-node measures the various rates, or else may be sent occasionally (see "optional report suppression", for instance in [ref])
*	S2.2, concatenating the flow Ids raises too many issues on format, order, what a flow ID is etc. Delete
*	The phrasing needs to be better in several places, eg the abstract, the latter part of para 1 & para 2 of Intro. 
*	Also S2.3.3 "The signaling protocol MUST be able to carry identification (address information) of the PCN edge nodes." -> "The signaling protocol MUST carry the identity of the PCN-egress-node that sends the message." The rest of the section can be deleted. Similar comment about 2.3.4. S2.3.5 can be shortened to "The load generated by the signaling protocol SHOULD be minimized.". 
*	S3 is hard to understand. It can be much shorter; similar to S2 it should be confined to signalling; something like "Request - response signalling is used" would clarify it. 
*	S2.1 title - delete "PCN". Delete last sentence [nothing to do with the sub-section]
*	S2.2, title, delete "Signalled"
*	S2.4 something here needs to be capitalised. 

Question: S1, para 2, here and elsewhere you say the signalling is "towards" the decision point. Why don't you say "to" the decision point?  Is this because you're thinking the msg could piggy-back on some existing signalling (like rsvp)? If yes, i think it would be better to spell this out specifically:
<<Signaling needs to transport:
*	PCN egress feedback, from a PCN-egress-node to the decision point
*	A request, from the decision point to a PCN-ingress-node, that triggers the PCN-ingress-node to measure the PCN-sent-rate
*	PCN ingress feedback, from a PCN-ingress-node to the decision point. 
A signalling message may either be sent directly, or may piggy-back on some other message that is being sent via the relevant node.>>

Security
I don't see why msg authentication & integrity, anti-DOS measures are a SHOULD. The base assumption of PCN architecture is that PCN operates within a trusted domain, ie all nodes in the domain are trusted. So it's ok providing the msg comes from an interface internal to the PCN-domain.
I don't understand the msg confidentiality bullet. When would PCN signalling msgs be visible to non-autorsied nodes; and if there is such a case, where is msg confidentiality only a MAY? The reqt surely is that msgs don't leak out of the PCN-domain - which should be easy since msgs are sent to the PCN-boundary-node's address

Replace S2.3.7 with something like the following:-
The PCN architecture [ref] assumes that all PCN-nodes are PCN-enabled and trusted to operate correctly. In the context of this document:
* PCN-signalling messages MUST NOT leak out of the PCN-domain (+)
* PCN-boundary-nodes MUST validate the signalling messages, to avoid that they come from an attacker (*)
(+) should be easy, since msgs are sent to the PCN-boundary-node's address
(*) one way is simply: does the msg arrive on an interface internal to the PCN-domain? If yes, it isn't from an attacker, since all PCN-nodes are trusted

Terminology
*	consistently use terminology from 5559: PCN-traffic, PCN-ingress-node, PCN-egress-node ETC etc
*	use terminology from the edge behaviour docs - PCN-sent-rate, NM-rate, ETM-rate, THM-rate, CLE could all be re-used (and CLE is badly defined here)
*	decision point, delete "of course"
*	PCN egress feedback - definition could be better. I think the "feedback" is the report (not the "content") "A report sent by the PCN-egress-node to the decision point; it reports measurements made by the PCN-egress-node that inform decisions about flow admission and flow termination"
*	PCN ingress feedback - similar. Also, does the report ever include anything other than PCN-sent-rate?
*	"A report sent by the PCN-ingress-node to the decision point; it reports measurements(*) made by the PCN-ingress-node that inform decisions about flow termination"  (*) or "the measurement of PCN-sent-rate"
*	I'd delete "Ingress rate request". It's easy to refer to this as a request for PCN ingress feedback

Best wishes
phil
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steven Blake
Sent: 21 October 2010 15:29
To: Georgios Karagiannis
Cc: [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-signaling-requirements-01.txt?

Ok, thanks Georgios.

Regards,

// Steve

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Oct 2010 11:17:17 +0200

Hi Phil

Thank you very much for the comments!

I will provide detailed answers later on, but now I would like to emphasize
that regarding the signaling draft 
the WG have had agreed on the following:

The PCN content that was specified in the current WG boundary behaviour
drafts  will be the PCN content that 
needs to be signaled between the PCN edge nodes and the decision point. 

Thus what the signaling draft currently is doing is listing the PCN content
that is specified in the CL and SM edge behaviour drafts and based on this
content
it specifies requirements on how signaling protocols should be used to
signal this content between the edge nodes and the decision point!

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: dinsdag 26 oktober 2010 12:14
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] WGLC for 
> draft-ietf-pcn-signaling-requirements-01.txt?
> 
> *	It repeats a lot of the edge behaviour docs. If i get 
> it right, this doc is supposed to be *just* about the 
> signalling (the requirements for signalling) - the edge node 
> behaviour docs talk about the *content* that is signalled. To 
> take just one example:
> o	S2.2 starts by listing what the PCN-egress-node 
> measures - but this doc should be about reports - reporting 
> the info that's been measured (reference edge behaviour doc 
> for details of what is measured)
> o	The list anyway doesn't match the edge behaviour docs 
> (CLE may or may not be calculated by PCN-egress-node)
> *	The terminology should consistently re-use what has 
> already been defined in our RFCs and what is defined in the 
> edge behaviour docs. See below. 
> *	The sub-section headings of S2 & S3 should match. This 
> might help S3 to be re-written more clearly. 
> *	S2.2: I don't think report suppression should be 
> mentioned here as a compulsory feature. This is to do with 
> specific signalling examples (CL, SM) and not a general 
> feature required of all imaginable PCN edge signalling. 
> Report suppression is a feature of the edge behaviour. At 
> most this doc should say something like "A report may either 
> be sent periodically, every time the PCN-egress-node measures 
> the various rates, or else may be sent occasionally (see 
> "optional report suppression", for instance in [ref])
> *	S2.2, concatenating the flow Ids raises too many issues 
> on format, order, what a flow ID is etc. Delete
> *	The phrasing needs to be better in several places, eg 
> the abstract, the latter part of para 1 & para 2 of Intro. 
> *	Also S2.3.3 "The signaling protocol MUST be able to 
> carry identification (address information) of the PCN edge 
> nodes." -> "The signaling protocol MUST carry the identity of 
> the PCN-egress-node that sends the message." The rest of the 
> section can be deleted. Similar comment about 2.3.4. S2.3.5 
> can be shortened to "The load generated by the signaling 
> protocol SHOULD be minimized.". 
> *	S3 is hard to understand. It can be much shorter; 
> similar to S2 it should be confined to signalling; something 
> like "Request - response signalling is used" would clarify it. 
> Question: S1, para 2, here and elsewhere you say the 
> signalling is "towards" the decision point. Why don't you say 
> "to" the decision point?  Is this because you're thinking the 
> msg could piggy-back on some existing signalling (like rsvp)? 
> If yes, i think it would be better to spell this out specifically:
> *	A request, from the decision point to a 
> PCN-ingress-node, that triggers the PCN-ingress-node to 
> measure the PCN-sent-rate
> A signalling message may either be sent directly, or may 
> piggy-back on some other message that is being sent via the 
> relevant node.>>
> 
> Security
> I don't see why msg authentication & integrity, anti-DOS 
> measures are a SHOULD. The base assumption of PCN 
> architecture is that PCN operates within a trusted domain, ie 
> all nodes in the domain are trusted. So it's ok providing the 
> msg comes from an interface internal to the PCN-domain.
> I don't understand the msg confidentiality bullet. When would 
> PCN signalling msgs be visible to non-autorsied nodes; and if 
> there is such a case, where is msg confidentiality only a 
> MAY? The reqt surely is that msgs don't leak out of the 
> PCN-domain - which should be easy since msgs are sent to the 
> PCN-boundary-node's address
> 
> Replace S2.3.7 with something like the following:- The PCN 
> architecture [ref] assumes that all PCN-nodes are PCN-enabled 
> and trusted to operate correctly. In the context of this document:
> * PCN-boundary-nodes MUST validate the signalling messages, 
> to avoid that they come from an attacker (*)
> (*) one way is simply: does the msg arrive on an interface 
> internal to the PCN-domain? If yes, it isn't from an 
> attacker, since all PCN-nodes are trusted
> 
> Terminology
> *	consistently use terminology from 5559: PCN-traffic, 
> PCN-ingress-node, PCN-egress-node ETC etc
> *	use terminology from the edge behaviour docs - 
> PCN-sent-rate, NM-rate, ETM-rate, THM-rate, CLE could all be 
> re-used (and CLE is badly defined here)
> *	PCN egress feedback - definition could be better. I 
> think the "feedback" is the report (not the "content") "A 
> report sent by the PCN-egress-node to the decision point; it 
> reports measurements made by the PCN-egress-node that inform 
> decisions about flow admission and flow termination"
> *	PCN ingress feedback - similar. Also, does the report 
> ever include anything other than PCN-sent-rate?
> *	"A report sent by the PCN-ingress-node to the decision 
> point; it reports measurements(*) made by the 
> PCN-ingress-node that inform decisions about flow 
> termination"  (*) or "the measurement of PCN-sent-rate"
> *	I'd delete "Ingress rate request". It's easy to refer 
> to this as a request for PCN ingress feedback
> 
> Best wishes
> phil
> Subject: Re: [PCN] WGLC for 
> draft-ietf-pcn-signaling-requirements-01.txt?
> 
> The WGLC for draft-ietf-pcn-signaling-requirements-01 starts 
> today, concluding Thursday, Nov. 4.  Please send comments to 
> the pcn list.
> 
> 
> Regards,
> 
> // Steve
>