Subject: [PCN] Fwd: Re: WGLC for draft-ietf-pcn-encoding-comparison-04.txt

From: Michael Menth <[email-masked]>
Date: Tue, 29 Mar 2011 14:32:12 +0200

Hi Georgios,

here are again my comments on the encoding draft. I just resend them 
that they don't get lost. Please fix these issues in the next version of 
the draft!

Best wishes,

     Michael

-------- Original-Nachricht --------
Betreff: 	Re: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt
Datum: 	Mon, 21 Mar 2011 17:47:51 +0100
Von: 	Michael Menth <[email-masked]>
An: 	Steven Blake <[email-masked]>, "[email-masked]" <[email-masked]>

Hi all,

I reviewed the encoding-comparison draft. I have mainly a few editorial
comments that can be found in the attached document.

not-PCN, not-marked, currently unused: upper- or lowercase? Consistency
needs to be checked! My preference is lowercase.

I did not understand the Security section. It needs a major rewrite.
What are PCN End Nodes?

I browsed over the Appendix. I find it rather irrelevant. It is rather
misleading than helpful and should be dropped.

Apart from that, I find the document very informative.

Best wishes,

      Michael

Am 08.03.2011 05:35, schrieb Steven Blake:
>  This begins the WGLC for:
>
>  http://tools.ietf.org/html/draft-ietf-pcn-encoding-comparison-04
>
>  to end on Tuesday, March 22.  Please send comments to the list.
>
>  As a reminder, we are still in WGLC for
>  draft-ietf-pcn-3-in-1-encoding-04, to end next Monday.
>
>
>  Regards,
>
>  // Steve
>
>  _______________________________________________
>  PCN mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/pcn

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 13:43:38 +0100

(also to make sur enot lost!)

I think your major comments can be handled as:
Security section - replace with ref to architecture rfc (as the issues mentioned are covered there)
Appendix - I tihnk over lunch we agreed to delete this

thanks
phil

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Michael Menth [[email-masked]]
Sent: 29 March 2011 13:32
To: [email-masked]
Subject: [PCN] Fwd: Re: WGLC for draft-ietf-pcn-encoding-comparison-04.txt

Hi Georgios,

here are again my comments on the encoding draft. I just resend them that they don't get lost. Please fix these issues in the next version of the draft!

Best wishes,

    Michael

-------- Original-Nachricht --------
Betreff:        Re: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt
Datum:  Mon, 21 Mar 2011 17:47:51 +0100
Von:    Michael Menth <[email-masked]><mailto:[email-masked]>
An:     Steven Blake <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Hi all,

Best wishes,

     Michael

Am 08.03.2011 05:35, schrieb Steven Blake:
> [email-masked]<mailto:[email-masked]>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 29 Mar 2011 15:46:13 +0000

Hi all

I have checked the comments of Phil and Michael! Regarding the comments
of Michael I have not replied yet to the mailing list.

I agree with all comments, but for reasons of clarity I am listing below
a subset of them that I consider the most signifficant!

---------------
Issue 1: remove all text from S6 and refer to the security
implications section given in [RFC5559]
Georgios: Comment will be worked out!

Issue 2: Appendix: A quick scan suggested it seems ok but there are quite
a few typos. Maybe it will the appendix could be replaced by a comment:
"A longer discussions of the issues and some further encoding options
that were considered can be found in the Appendix of [ref] (a pre-RFC
version of this document)
Georgios: Comment will be worked out, i.e., the Appendix will be removed
and the above text (regarding the longer discussion) will be included in
the Introduction section.

Issue 3: not-PCN, not-marked, currently unused: upper- or lowercase?
Consistency needs to be checked! Michaels preference is lowercase.
Georgios: I will use lowercase!

---------------

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 29 Mar 2011 16:07:17 +0000

Hi Michael, Hi all

I have read the comments of Michael on the signaling drafts. As I already
mentioned I am happy with most of the comments but I have problems with
the following changes Michael proposed on the signaling requirements
draft, which I have denoted as issues:

-----------------------------------

Issue 1 (comment Michael): For the following bullet, should we say the
IPv4 or IPv6 address
of the nodes to be more specific?
o identifiers of the PCN-ingress-node and the PCN-egress-node that
specify the ingress-egress-aggregate to which the report refers,

Georgios: Is it necessary to be that specific?

--------------------

Issue 2 (comment Michael): Regarding flow identifiers, the following is
not needed:
   o IP address of PCN-ingress-node;
   o IP address of PCN-egress-node

Georgios: If you do not include the above addresses then an aggregated
flow will not be able to be identified!

-----------------------

Issue 3  (comment Michael): requirement "2.3.2 Local information"
exchange does not need
to be explicitly stated.

Georgios: It is very important, because if you do not state that then a
signaling protocol may carry this content up to the end (when they are
e.g. piggibacked), while it
should be used only locally.
So it is a signaling requirement, which is by the way also used in other
signaling requirements RFCs.

-------------

Issue 4 (comment Michael): Remove section "2.3.3 Carry identification of
PCN edge nodes“
since it is part of the content.

Georgios: I do not understand your comment. The identification of the PCN
edge nodes might not be a part of the content.
The signaling protocol must ensure that the identification of the PCN
edge nodes is a part of the message.
Therefore this requirement must be there.

----------------

Issue 5  (comment Michael): Remove section "2.3.4 Carry identification of
ingress-egress-aggregates“ since it is a part of the content.

Georgios: I do not understand your comment. The identification of the
ingress-egress-aggregate might not be a part of the content.
The signaling protocol must ensure that the identification of the the
ingress-egress-aggregate is a part of the message.
Therefore this requirement must be there.

----------------------

Issue 6  (comment Michael): Add the following text to “Signaling load”
requirement:
We give two examples that may help to achieve that goal:
o Piggy-backing the reports by the PCN-egress-nodes to the decision
point(s) onto other signaling messages that are already in place
o Reducing the amount of reports to be sent by optional report
suppression.

Georgios: Is this text required?

------------------

Issue 7  (comment Michael): Removed the following text from the Security
requirement:
As PCN reports are sent regularly, additional reliability mechanisms are
not needed. This also holds in the presence of optional report
suppression, as reports are sent periodically if actions by the decision
point(s) are needed.
PCN-signaling messages MUST NOT leak out of the PCN-domain. This can be
easily accomplished, since messages are sent to the PCN-boundary-node's
address;
PCN-boundary-nodes MUST validate the signaling messages, to avoid that
they come from an attacker. Considering that all PCN-nodes are trusted,
see [RFC5559], this requirement could be easily fulfilled by verifying
whether a message arrives on an interface internal to the PCN-domain.

Georgios: This text was provided by Phil, which I agree with.

-----------------------------

Issue 8 (comment Michael): Removed completely old section 3 and included
new sections.

--------------------

3. Signaling Requirements for Messages between Decision Point(s) and
PCN-Ingress-Nodes

   The decision point may require the PCN-sent-rate for a specific
ingress-egress-aggregate and request it from the corresponding
PCN-ingress-node. The PCN-ingress-node measures the rate of admitted PCN
traffic and reports it to the requesting decision point. Signaling for
that purpose is needed only if decision point and PCN-ingress-node are
not collocated. In the following, the contents of these request and
report messages and the requirements for the signaling protocols that
carry them are described.

3.1 Contents of Requests by the Decision Point(s)

The request contains
o an indication that the PCN-sent-rate is requested
o the identifier of the PCN-ingress-node and the PCN-egress-node that
determine the ingress-egress-aggregate for which the PCN-sent-rate is
requested
o the identifier of the decision point that requests the PCN-sent-rate

3.2 Contents of Reports by the Decision Point(s)

The report contains
o an indication that the reported data is a PCN-sent-rate
o the PCN-sent-rate in octets/second
o the identifiers of the PCN-ingress-node and the PCN-egress-node that
determine the ingress-egress-aggregate to which the measured
PCN-sent-rate refers

3.3 Requirements for the Signaling Protocol that Carries Data between the
Decision Point(s) and PCN-Ingress-Nodes

The request messages MUST be addressed to the PCN-ingress-nodes.
The report messages MUST be addressed to the decision point(s).

The requests by the decision points and the reports by the
PCN-ingress-nodes are sent only when flow termination is needed. As flow
termination is an urgent action, it is important that the messages
arrive quickly and reliably. This implies that these messages SHOULD be
sent
o with high priority
o in a reliably fashion

-----------------

Georgios: I found the proposed section 3.3 (by Micheal) very abstract and
very unclear! One cannot clearly identify the signaling requirements,
since you combined them all in a couple of sentences! Therefore, it is
needed that similar 3.3 subsections are used as the ones in Section 2.2.

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Wed, 30 Mar 2011 19:34:38 +0200

Hi Georgios,

to shorten the WG session on Friday ...

> draft, which I have denoted as issues:

I just said when the egress sends a report, the address of the egress 
does not explicitly included in the report as this egress sends this 
report. I can live with this redundancy.

The way this point was formulated was not understandable to me. From my 
perspective, it is trivial that the protocol must be able to exchange 
information with the adressee.

Ok, now I understand your concern. You probably mean that if the 
information is piggybacked onto RSVP, the source of the signalling 
message might not reveal the egress node that adds PCN information. Then 
I would say it is easier that the contents should reveal this 
information which we can make mandatory.

It is reasonable that the identification is part of the content as 
mentioned in a previous section.

Short examples are always good if they do not cost time to read and if 
they are not wrong. I dont't think that this text is excessive.

This text is about reliability and not about security and this issue has 
already been covered in the doc.

> easily accomplished, since messages are sent to the PCN-boundary-node's
The issue with traffic leaking out of a PCN domain was about the 
markings. This text seems to me like a non-issue.

> Georgios: This text was provided by Phil, which I agree with.
I think the fact that RFC5559 assumes a trusted domain covers this. I 
would not say more, in particular if it does not give more information.

I don't know what remains unclear to you. think that the text does not 
improve if it becomes longer and less concrete.

Michael

---

From: Steven Blake <[email-masked]>
Date: Wed, 30 Mar 2011 22:02:50 -0400

I am seeing rough consensus for a set of edits to be applied to this
draft.

Editors: please revise the draft, and we will run an abbreviated WGLC.

Thanks to all who participated in the discussion.

Regards,

// Steve