Subject: [PCN] additional issue with comments on signaling requirements draft

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 01 Apr 2011 08:43:50 +0000

Hi all

I have omitted to mention the following additional issue with one of the
comments of Michael. The issue is related to the new requirement
proposed by Michael on Destination address:

"Destination Address:
The signaling message MUST be addressed to the decision point(s)."

If this requirement is included then piggybacking the content on an
end-to-end signaling protocol is not anymore possible.

Best regards,
Georgios

On 3/29/2011, "Georgios Karagiannis" <[email-masked]> wrote:

>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
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Fri, 01 Apr 2011 10:47:27 +0200

> end-to-end signaling protocol is not anymore possible.

To avoid long discussions during the WG meeting: I have no problem with 
reformulating it to "The signaling message MUST reach the decision 
point(s). ". This is indeed a rather trivial requirement that we can 
possibly skip. It was a left-over from the previous version.

Best wishes,

Michael

> Best regards,
> Georgios
>
>
> On 3/29/2011, "Georgios Karagiannis"<[email-masked]>  wrote:
>
>> Hi Michael, Hi all
>>

-- 
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