Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.txt (all DISCUSSES and comments worked out)

From: <[email-masked]>
Date: Thu, 9 Feb 2012 00:32:41 +0000

Hi all,

The co-authors of the draft have worked out all DISCUSSES and all received comments in draft: draft-ietf-pcn-signaling-requirements-08.txt. This draft has been submitted some minutes ago!

The DISCUSSES and comments are worked out in the following way:

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

=> worked out the DISCUSS entered by Stewart Bryant in the following way:

> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> "The representation of a PCN-flow identifier depends on the  surrounding
> environment, e.g., pure IP, MPLS, GMPLS, etc.
>  Examples of such PCN-flow identifier representations can be found in
> [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. "
> 
> 
> The above text implies that it is a simple matter to identify
> and represent an MPLS flow. I do not believe this to be the case.
> The authors should either specify how they propose to
> represent MPLS flows (as they do for IP) or note that this
> is a problem that needs to be solved.
> 
Georgios: I think that we have written something else than what we meant!
What we actually written is solution oriented and should be modified, please see below:
Thus section 2.1 is removed.
"2.1 Specification of PCN-Flow Identifiers
     The representation of a PCN-flow identifier depends on the
     surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
     Examples of such PCN-flow identifier representations can be found in  [RFC2205], [RFC3175]   
    [RFC3209], [RFC3473], [RFC4804].
    In pure IP networks, the identifier may consist of a subset of the
     following information:
     o  source IP address;
     o  destination IP address
     o  protocol identifier and higher layer (port) addressing
     o  flow label (typical for IPv6)
     o  SPI field for IPsec encapsulated data
     o  DSCP/TOS field
     Note, where a PCN-flow consists of a collection of microflows, then
     the PCN-flow is identified by the PCN-ingress-node's and PCN-egress-
     node's identifiers (typically their IP addresses), which are already
     part of the report."

 The following paragraph is introduced instead!
 "As described in [draft-ietf-pcn-cl-edge-behaviour], PCN reports 
from the PCN-egress-node to the decision point may contain flow identifiers for Individual flows within an ingress-egress-aggregate that have recently experienced excess-marking. Hence,  the PCN report messages used by the PCN CL edge behaviour MUST be capable of carrying sequences of octet strings constituting such identifiers."

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

=> worked out the DISCUSS and COMMENT entered by Adrian Farrel in the following way:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> In Section 2 (and repeated in 3)
> 
>    Signaling messages SHOULD have a higher priority than data packets to
>    deliver them quickly and to avoid that they are dropped in case of
>    overload.
> 
> Unless I am mistaken, there is a difference between priority and drop 
> precedence.
Georgios: Agree with the observation. This text will be changed INTO:
Signaling messages SHOULD have a higher priority and a lower drop precedence than PCN-packets, see [RFC5559], to deliver them quickly and to avoid that they are dropped in case of overload.
> 
> Can you also clarify whether you mean all data packets, or justdata 
> packets on the measured flow.
Georgios: We meant PCN-packets, see [RFC5559]:
"o  PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of
      different Diffserv behaviour aggregates (BAs) [RFC2474].  The
      PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the
      corresponding packets are PCN-packets.  The same network will
      carry traffic of other Diffserv BAs.  The PCN-BA is distinguished
      by a combination of the Diffserv codepoint (DSCP) and ECN fields." From [RFC5559]

> 
> ---
> 
> I have a point that is very similar to Stewart's...
> 
>    The representation of a PCN-flow identifier depends on the
>    surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
>    Examples of such PCN-flow identifier representations can be found in
>    [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804].
> 
> I don't find any mentiong of PCN in those documents, so I think you 
> mean "Identifiers for flows can be found in [foo]. These identifiers 
> can be used in PCN to identify the flows that are measured and reported on."
> 
> Thinking about it, the wider problem may be that the discussion in 2.1 
> is actually solution-oriented. The requirements are to be able to 
> apply PCN to a specific set of flows, and that the flow about which 
> PCN is being signaled should be unambiguously identified. Those requirements are worth stating.
> You might even say tat there is a requirement that the data packets 
> not be encumbered by any additional fields used for flow 
> identification, therefore all flow identifiers must utilize only fields already present in the data headers.
> [At this point you might aslo comment on how deep it is acceptable to 
> look - e.g., can you look below a top MPLS label?]
> 
> But the discussion of which identifiers are suitable is surely not a 
> matter for a requirements document.
Georgios: I agree, we removed Section 2.1, see below:

"2.1 Specification of PCN-Flow Identifiers
     The representation of a PCN-flow identifier depends on the
     surrounding environment, e.g., pure IP, MPLS, GMPLS, etc.
     Examples of such PCN-flow identifier representations can be found in  [RFC2205], [RFC3175]   
    [RFC3209], [RFC3473], [RFC4804].
    In pure IP networks, the identifier may consist of a subset of the
     following information:
     o  source IP address;
     o  destination IP address
     o  protocol identifier and higher layer (port) addressing
     o  flow label (typical for IPv6)
     o  SPI field for IPsec encapsulated data
     o  DSCP/TOS field
     Note, where a PCN-flow consists of a collection of microflows, then
     the PCN-flow is identified by the PCN-ingress-node's and PCN-egress-
     node's identifiers (typically their IP addresses), which are already
     part of the report."

 The following paragraph is introduced instead!
 "As described in [draft-ietf-pcn-cl-edge-behaviour], PCN reports 
from the PCN-egress-node to the decision point may contain flow identifiers for Individual flows within an ingress-egress-aggregate that have recently experienced excess-marking. Hence,  the PCN report messages used by the PCN CL edge behaviour MUST be capable of carrying sequences of octet strings constituting such identifiers."

> 
> ---
> 
> Section 4
> 
>    [RFC5559] provides a general description of the security
>    considerations for PCN. This memo does not introduce additional
>    security considerations.
> 
> I agree with the statement about RFC 5559. But surely this 
> requirements document places security-related requirements on the PCN signaling.
> These should be noted in this section.
Georgios: the following text is introduced instead!
   [RFC5559] provides a general description of the security  
   considerations for PCN. This memo relies on the  security-related 
   requirements on the PCN signalling, provided in [RFC5559].  In 
   particular, the signaling between the PCN-boundary-nodes must be  
   protected  from attacks.  For example, the recipient needs to 
   validate that the message is indeed from the node that claims to have 
   sent it. Possible measures include digest authentication and 
   protection against replay and man-in-the-middle attacks. For the 
   generic aggregate RSVP protocol, specifically, additional protection 
   methods against security attacks are described in [RFC4860].

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> You should remove the citations from the Abstract.
> 
Georgios: Agree!
 The following references are removed from the abstract:
[draft-ietf-pcn-cl-edge- behaviour-09], 
   [draft-ietf-pcn-sm-edge-behaviour-06].
-------------

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

==> worked out the COMMENT entered by Stephen Farrell in the following way:

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> I just note that 5559 which is referenced here says "The signalling between
> the PCN-boundary-nodes must be protected from attacks."
> So I'm counting on the eventual protocol document meeting that goal.
Georgios: Please note that, we modified Section 4 in the following way:
  [RFC5559] provides a general description of the security  
   considerations for PCN. This memo relies on the  security-related 
   requirements on the PCN signalling, provided in [RFC5559].  In 
   particular, the signaling between the PCN-boundary-nodes must be  
   protected  from attacks.  For example, the recipient needs to 
   validate that the message is indeed from the node that claims to have 
   sent it. Possible measures include digest authentication and 
   protection against replay and man-in-the-middle attacks. For the 
   generic aggregate RSVP protocol, specifically, additional protection 
   methods against security attacks are described in [RFC4860].

==============================================================
==> worked out the comment from David Harrington 
> "Shouldn't the signaling from PDP to PEP be included in these requirements?
> Reporting the information to a non-colocated Decision Point doesn't do much
> if there is no signaling protocol from the Decision Point to the Enforcement
> Point.
> I think there should be some discussion in the document of how
> deployments are expected to handle this (e.g. operational
> considerations) if the PCN WG considers it not in-scope."
We would like to include the following text, which has been proposed by Tom. 
"Note that a complete system description for a PCN domain with 
   centralized Decision Point includes the signaling from Decision Point 
   to the PCN-ingress-nodes to control flow admission and termination. 
   However, this is a known problem whose solutions were given by, 
   for example, [RFC3084] or [RFC5431], and it lies outside the scope of 
   the present document."

=======================
==> comments from Francis Dupont:
> Van: [email-masked] [[email-masked]]
> Verzonden: zaterdag 14 januari 2012 10:13
> Aan: [email-masked]
> CC: [email-masked]
> Onderwerp: review of draft-ietf-pcn-signaling-requirements-07.txt
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call
comments
> you may receive.
>
> Document: draft-ietf-pcn-signaling-requirements-07.txt
> Reviewer: Francis Dupont
> Review Date: 20120106
> IETF LC End Date: 20120113
> IESG Telechat date: unknown
>
> Summary: Ready
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>  - in the whole document: behaviour -> behavior and
> signalling -> signaling
>   (note the spelling of collocated is dubious too)
Georgios: Solved!
>
>  - Abstract page 1: in the latter case -> in the first case
Georgios: done!
>
>  - Abstract page 1: the usage is to not refer to RFC in the Abstract
Georgios: done!
>
>  - ToC page 2: Acknowledgements -> Acknowledgments
Georgios: done!
>
>  - 2 page 3: measures- -> measures (in general the document is at
>  the limit of abuse of '-' character, here it is clearly a typo)
Georgios: done
>
>  - 6 page 6: Acknowledgements -> Acknowledgments
Georgios: done
>
>  - 6 page 6: I don't like the term 'generated', IMHO you can easily
>   find a better/nicer term.
GeorgiosL done (used => produced)
>
>  - 7.2 page 7: C. Le Faucher, -> C., Le Faucheur,
Georgios: the reference in removed!
==========================

=> Followed comments/suggestions provided by Tom, Michael and Phil  and removed the bullets from Section 2:
 
  o congestion-level-estimate, which is a number between zero and 
     one.
===========================

All: Thank you very much for the comments!

Best regards,
Georgios
                         ^          ^

________________________________________
Van: [email-masked] [[email-masked]] namens [email-masked] [[email-masked]]
Verzonden: donderdag 9 februari 2012 1:18
Aan: [email-masked]
CC: [email-masked]
Onderwerp: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.txt

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)       : Georgios Karagiannis
                          Tom Taylor
                          Kwok Ho Chan
                          Michael Menth
                          Philip Eardley
        Filename        : draft-ietf-pcn-signaling-requirements-08.txt
        Pages           : 7
        Date            : 2012-02-08

   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: (1) PCN-feedback-information is carried from the PCN-egress-
   node to the decision point;(2) the decision point may ask the PCN-
   ingress-node to measure, and report back, the rate of sent PCN-
   traffic between that PCN-ingress-node and PCN-egress-node. The
   decision point may be either collocated with the PCN-ingress-node or
   a centralized node (in the first case, (2) is not required). The
   signaling requirements pertain in particular to two edge behaviors,
   "controlled load (CL)" and "single marking (SM)".

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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-08.txt

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