Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain
draft-ietf-pcn-signaling-requirements-08

[Ballot 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.

[Ballot 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.

Can you also clarify whether you mean all data packets, or justdata
packets on the measured flow.

---

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.                               

---

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.

[Ballot comment]
A question for the responsible AD...

The PROTO writeup states:

      The -03 version generated significant debate on the working group
      mailing list during WGLC.  The editor addressed the comments
      to everyone's satisfaction.  There are no vocal dissenters.

Just curious: what were the topics that generated significant debate? It would be helpful to mention those in the ballot writeup.

[Ballot 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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <pcn@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-pcn-signaling-requirements-07.txt> (Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Requirements for Signaling of (Pre-) Congestion Information in a
  DiffServ Domain'
  <draft-ietf-pcn-signaling-requirements-07.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 latter case, (2) is not required). The
  signaling requirements pertain in particular to two edge behaviours,
  "controlled load (CL)" and "single marking (SM)"
  [draft-ietf-pcn-cl-edge- behaviour-09],
  [draft-ietf-pcn-sm-edge-behaviour-06].





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/


No IPR declarations have been submitted directly on this I-D.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <pcn@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-pcn-signaling-requirements-07.txt> (Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Requirements for Signaling of (Pre-) Congestion Information in a
  DiffServ Domain'
  <draft-ietf-pcn-signaling-requirements-07.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 latter case, (2) is not required). The
  signaling requirements pertain in particular to two edge behaviours,
  "controlled load (CL)" and "single marking (SM)"
  [draft-ietf-pcn-cl-edge- behaviour-09],
  [draft-ietf-pcn-sm-edge-behaviour-06].





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document?

>      Steven Blake, PCN co-chair <slblake@petri-meat.com>
 
        Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

>      Yes & yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?
       
>      WG members - Yes
       
        Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

>      No

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

>      No

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.
       
>      The shepherd expects that there are additional requirements
>      (e.g., congestion control) that are generic to any Internet
>      protocol, that are not explicitly captured in this draft, but
>      expects that as the working group begins to define (or adapt)
>      one or more signaling protocols, that these requirements will
>      be taken into account.
       
        In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.
       
>      These concerns were not raised in the discussion of this draft
>      (blame the shepherd).
       
        Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

>      No

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

>      The -03 version generated significant debate on the working group
>      mailing list during WGLC.  The editor addressed the comments
>      to everyone's satisfaction.  There are no vocal dissenters.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

>      No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

>      The document passes ID-nits with one warning: Page 2 is 59 lines
>      long.  An update correcting this issue (-07) will be posted.


  (1.h) Has the document split its references into normative and
        informative?
       
>      Yes.
       
        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

>      There are references to draft-ietf-pcn-cl-edge-behaviour-09 and
>      draft-pcn-sm-edge-behaviour-06.  The immediate predecessors to
>      each document were forwarded to the IESG, but GEN-ART and AD
>      review raised several comments that need to be addressed by the
>      working group for each document before they can be progressed.
>      The working group is actively addressing these issues, and these
>      documents should be ready to be re-advanced in the next few months.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?
       
>      An IANA Considerations section exists, but no requests are
>      made to IANA.
       
        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

>      Not applicable

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

>      Not applicable

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

>      PCN (RFC 5559) conveys pre-congestion information to an egress
>      router via in-band packet marking.  This document defines the
>      requirements for signaling protocols that convey PCN feedback
>      information from a PCN egress router to a PCN decision point,
>      and between the decision point and a PCN ingress router (if they
>      are not co-located).  The signaling requirements apply specifically
>      to the Single Marking and Controlled Load PCN edge behaviours being
>      defined in the PCN working group.

    Working Group Summary

>      The document was subject to thorough review by the PCN working
>      group, and strong consensus for publication was reached.

    Document Quality

>      The document was reviewed by the document shephard (Steven Blake).