Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
draft-ietf-pcn-3-in-1-encoding-11

[Ballot discuss]
Discuss updated for -09

I am going to hold this Discuss point while I wait to hear the WG's
conclusion on whether to pursue documentaiton of the other encooding
methods.

It appears that there are a number of alternative encoding being
proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding,
draft-ietf-pcn-psdm-encoding, etc., and as discussed in
draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these
encodings are being proposed to co-exist, to be used by different
operators depending on specific environments, or whether they are being
floated to see which one gets more market-place support.

In the latter case, I would have thought that the encoding documents
would have been Experimental.

I might also have expected some mention of the other I-Ds if all of
the solutions are to be completed by the WG.

[Ballot comment]
Thanks for the work to address my Discuss and Comments.

---

The change at the end of 4.2 does seem to address my concern in 4.3,
but leaves the text in 4.3 looking rather strange: every node MUST be
configured although 4.2 says that if that doesn't happen it will not
be the end of the world.

---

The substantial change to 5.1 addresses my Discuss, thanks. There seems
to be a lot of new material here, including 2119 language. Is the WG
on board with the new text?

---

I would have liked to see more discssion in a single place about
interactions with management. There are several places where alarms or
notifications are discussed and quite a number of things that are
configurable.

There is also the question of how a PCN system may be diagnosed.

Your AD may be able to point you at an RFC that provides guidance :-)

[Ballot discuss]
I am confuse about why this document is being published on the Standards Track as opposed to EXPERIMENTAL. The two documents that describe how these markings are used are both EXPERIMENTAL. Why not this one, too?

[Ballot comment]
"emphatically NOT RECOMMENDED" looks kinda like a cool new 2119 term, but it's not defined there and probably shouldn't be used. (I note that it isn't capitalized in Appendix B.) Maybe better would be "Implementation SHOULD NOT engage in this behavior except in the most extreme circumstances because..."

"This appendix is informative, not normative." I find this sentence to be an increasingly used verbal tic in documents. I think it's useless and should be removed. In the case of Appendix A, you already say at the end that "operators are ultimately free to" use PCN or not. In Appendix B, you remind the reader that in the event of a conflict between the appendix and the rest of the document, implementations should follow the guidelines in the rest of the document. This "informative vs. normative" distinction is just jargon that isn't necessary.

[Ballot discuss]
It appears that there are a number of alternative encoding being
proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding,
draft-ietf-pcn-psdm-encoding, etc., and as discussed in
draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these
encodings are being proposed to co-exist, to be used by different
operators depending on specific environments, or whether they are being
floated to see which one gets more market-place support.

In the latter case, I would have thought that the encoding documents
would have been Experimental.

I might also have expected some mention of the other I-Ds if all of
the solutions are to be completed by the WG.

---

I think [I-D.ietf-pcn-sm-edge-behaviour] and
[I-D.ietf-pcn-cl-edge-behaviour] are used normatively.

---                                                               

Section 4.3 has

  It may not be possible to upgrade every pre-RFC6040 tunnel endpoint
  within a PCN-domain.  In such circumstances a limited version of the
  3-in-1 encoding can still be used but only under the following
  stringent condition.  If any pre-RFC6040 tunnel endpoint exists
  within a PCN-domain then every PCN-node in the PCN-domain MUST be
  configured so that it never sets the ThM codepoint.  PCN-interior
  nodes in this case MUST solely use the Excess Traffic marking
  function, as defined in Section 5.2.3.1. 

I completely get this, but I am worried about accidents. What happens if
the operator thinks that they have upgraded all of the nodes, but have
actually missed one?

And then...

  In all other situations
  where legacy tunnel endpoints might be present within the PCN domain,
  the 3-in-1 encoding is not applicable.

But what happens if an attempt is made to use it?

In both cases, it is OK (probably/possibly) that the traffic using
3-in-1 will have problems, but quite another thing if other traffic is
impacted (for example, traffic using pre6040 tunnel endpoints. Can you
add text to say what happens?

---

Section 5.1

  If a PCN-packet arrives at the PCN-ingress-node with its ECN field
  already set to a value other than not-ECT, then appropriate action
  MUST be taken to meet the requirements of [RFC4774].  The simplest
  appropriate action is to just drop such packets.  However, this is a
  drastic action that an operator may feel is undesirable.  Appendix B
  provides more information and summarises other alternative actions
  that might be taken.

This is a protocol spec that tells implementers what to build. You can't
leave the behavior open like this.

At the very least you need to give a default behavior, state the other
possible behaviors, amke it clear which MUST be implemented, and require
a configuration option such that the operator can select.

BTW, a spec that says that "appropriate action MUST be taken" is not
helpful on two counts:

1. What action is appropriate?
2. Who MUST take the action?

[Ballot comment]
This document (6.2) implies that 5696 was never built or deployed. The
shepherd write-up doesn't mention any implementations or plans to
implement.

It is undeniable that the WG is chartered to work on this, but it is
unclear to me why this is Standards Track not Experimental if there
are no implementations

---

I wish the (current) limitation of applicability to IP-only networks
that is correctly noted at the end of the Introduciton was also noted in
the Abstract.

---

Section 1

  The full version of this encoding requires any tunnel endpoint within
  the PCN-domain to support the normal tunnelling rules defined in
  [RFC6040].

Could you clarify whether "this encoding" means "the encoding described
in this document" or "the encoding described in RFC 5696" (or somehting
different).

---

Section 3 begins...

  The 3-in-1 PCN encoding scheme allows for two or three PCN-marking
  states to be encoded within the IP header.

Hmmm. Does it allow 2 or 3 states to be encoded?
                                                                                                           
I think it allows 3, but in some cases you only need 2. So how about...

...supports foo that needs two PCN-marking states, and also bar that
  needs three PCN-marking states.

---

Section 4.1

  PCN-
  ingress-nodes mark them as Not-marked (PCN-colouring)

As the poster says: Defense d'afficher

---

I thin kyou can safely dispose of Section 9.

---

I would have liked to see more discssion in a single place about
interactions with management. There are several places where alarms or
notifications are discussed and quite a number of things that are
configurable.

There is also the question of how a PCN system may be diagnosed.

Your AD may be able to point you at an RFC that provides guidance :-)

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Encoding 3 PCN-States in the IP header using a single DSCP) to Proposed Standard





The IESG has received a request from the Congestion and Pre-Congestion

Notification WG (pcn) to consider the following document:

- 'Encoding 3 PCN-States in the IP header using a single DSCP'

  as a Proposed Standard



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





  The objective of Pre-Congestion Notification (PCN) is to protect the

  quality of service (QoS) of inelastic flows within a Diffserv domain.

  The overall rate of the PCN-traffic is metered on every link in the

  PCN domain, and PCN-packets are appropriately marked when certain

  configured rates are exceeded.  Egress nodes pass information about

  these PCN-marks to decision points which then decide whether to admit

  or block new flow requests or to terminate some already-admitted

  flows during serious pre-congestion.



  This document specifies how PCN-marks are to be encoded into the IP

  header by re-using the Explicit Congestion Notification (ECN)

  codepoints within a PCN-domain.  This encoding provides for up to

  three different PCN marking states using a single DSCP: not-marked

  (NM), threshold-marked (ThM) and excess-traffic-marked (ETM).  Hence,

  it is called the 3-in-1 PCN encoding.  This document obsoletes

  RFC5696.



  This document contains a normative reference to an informational RFC -

  RFC 5559 "Pre-Congestion Notification (PCN) Architecture".







The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/





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

[Ballot discuss]
Did the downref to 5559 get vetted per the RFC3967 process? (I agree with point in the ballot that the downref should be acceptable, but was the community asked?)

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Encoding 3 PCN-States in the IP header using a single DSCP) to Proposed Standard


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Encoding 3 PCN-States in the IP header using a single DSCP'
  as a Proposed Standard

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-02-23. 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


  The objective of Pre-Congestion Notification (PCN) is to protect the
  quality of service (QoS) of inelastic flows within a Diffserv domain.
  The overall rate of the PCN-traffic is metered on every link in the
  PCN domain, and PCN-packets are appropriately marked when certain
  configured rates are exceeded.  Egress nodes pass information about
  these PCN-marks to decision points which then decide whether to admit
  or block new flow requests or to terminate some already-admitted
  flows during serious pre-congestion.

  This document specifies how PCN-marks are to be encoded into the IP
  header by re-using the Explicit Congestion Notification (ECN)
  codepoints within a PCN-domain.  This encoding provides for up to
  three different PCN marking states using a single DSCP: not-marked
  (NM), threshold-marked (ThM) and excess-traffic-marked (ETM).  Hence,
  it is called the 3-in-1 PCN encoding.  This document obsoletes
  RFC5696.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/


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

this is a request from the PCN working group to publish
draft-ietf-pcn-3-in-1-encoding-08.txt
as a standards track RFC

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

Scott Bradner

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

(1.b) Has the document had adequate review both from key WG members
and from key non-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?

no

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 future of PCN is yet to be determined but if PCN is to succeed
this ID is an important part of the technology

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.

N/A

Has an IPR disclosure related to this document
been filed?

no

If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

N/A

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

good consensus

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

yes - there is one downref normative reference to an informational RFC
but since the RFC is an architecture document that seems OK

Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

N/A

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

yes

If such normative references exist, what is the
strategy for their completion?

they are in the final stages of development

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 is one downref normative reference to an informational RFC
but since the RFC is an architecture document that seems OK

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

yes

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?

N/A

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

N/A

(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

This document specifies how PCN-marks are to be encoded into the IP
header by re-using the Explicit Congestion Notification (ECN)
codepoints within a PCN-domain. This encoding provides for up to
three different PCN marking states using a single DSCP: not-marked
(NM), threshold-marked (ThM) and excess-traffic-marked (ETM).
Hence,
it is called the 3-in-1 PCN encoding. This document obsoletes
RFC5696.

Working Group Summary

the working group supported this revision of RFC 5696

Document Quality

the future of PCN is yet to be determined but if PCN is to succeed
this ID is an important part of the technology