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
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-04-24
|
11 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-04-23
|
11 | (System) | IANA Action state changed to No IC from In Progress |
2012-04-23
|
11 | (System) | IANA Action state changed to In Progress |
2012-04-23
|
11 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-04-23
|
11 | Amy Vezza | IESG has approved the document |
2012-04-23
|
11 | Amy Vezza | Closed "Approve" ballot |
2012-04-23
|
11 | Amy Vezza | Ballot approval text was generated |
2012-04-23
|
11 | Amy Vezza | Ballot writeup was changed |
2012-04-23
|
11 | Amy Vezza | Ballot writeup was changed |
2012-04-23
|
11 | Martin Stiemerling | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-04-20
|
11 | Bob Briscoe | New version available: draft-ietf-pcn-3-in-1-encoding-11.txt |
2012-04-17
|
10 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-03-29
|
10 | Martin Stiemerling | Responsible AD changed to Martin Stiemerling from David Harrington |
2012-03-22
|
10 | Cindy Morgan | New version available: draft-ietf-pcn-3-in-1-encoding-10.txt |
2012-03-19
|
09 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2012-03-19
|
09 | Adrian Farrel | [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 … [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. |
2012-03-19
|
09 | Adrian Farrel | [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 … [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 :-) |
2012-03-19
|
09 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-03-16
|
09 | Ron Bonica | [Ballot Position Update] Position for Ronald Bonica has been changed to No Objection from Discuss |
2012-03-15
|
09 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead |
2012-03-15
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2012-03-15
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-03-14
|
09 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-03-14
|
09 | Ron Bonica | [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 … [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? |
2012-03-14
|
09 | Ron Bonica | [Ballot Position Update] Position for Ronald Bonica has been changed to Discuss from No Objection |
2012-03-14
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-03-13
|
09 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
2012-03-13
|
09 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-03-13
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-11
|
09 | Pete Resnick | [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 … [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. |
2012-03-11
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-03-11
|
09 | Bob Briscoe | New version available: draft-ietf-pcn-3-in-1-encoding-09.txt |
2012-03-09
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-02-29
|
08 | Adrian Farrel | [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 … [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? |
2012-02-29
|
08 | Adrian Farrel | [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 … [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 :-) |
2012-02-29
|
08 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2012-02-28
|
08 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded for Peter Saint-Andre |
2012-02-28
|
08 | Amy Vezza | Last call sent |
2012-02-28
|
08 | Amy Vezza | 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: … 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. |
2012-02-28
|
08 | David Harrington | Telechat date has been changed to 2012-03-15 from 2012-03-01 |
2012-02-28
|
08 | David Harrington | Last call was requested |
2012-02-28
|
08 | David Harrington | Ballot approval text was generated |
2012-02-28
|
08 | David Harrington | State changed to Last Call Requested from Waiting for AD Go-Ahead |
2012-02-28
|
08 | David Harrington | Last call announcement was changed |
2012-02-28
|
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-02-28
|
08 | Stephen Farrell | [Ballot comment] The acronym PHB is used but not defined. |
2012-02-28
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-02-27
|
08 | Robert Sparks | [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 … [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?) |
2012-02-27
|
08 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Discuss from No Objection |
2012-02-27
|
08 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-02-27
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-02-27
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu |
2012-02-23
|
08 | Roni Even | Request for Last Call review by GENART Completed. Reviewer: Roni Even. |
2012-02-23
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-02-18
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2012-02-18
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2012-02-17
|
08 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2012-02-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-02-16
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-02-09
|
08 | Cindy Morgan | Last call sent |
2012-02-09
|
08 | Cindy Morgan | 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: … 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. |
2012-02-09
|
08 | David Harrington | Placed on agenda for telechat - 2012-03-01 |
2012-02-09
|
08 | David Harrington | Last Call was requested |
2012-02-09
|
08 | David Harrington | State changed to Last Call Requested from AD Evaluation. |
2012-02-09
|
08 | David Harrington | Last Call text changed |
2012-02-09
|
08 | David Harrington | [Ballot Position Update] New position, Yes, has been recorded for David Harrington |
2012-02-09
|
08 | David Harrington | Ballot has been issued |
2012-02-09
|
08 | David Harrington | Created "Approve" ballot |
2012-02-09
|
08 | (System) | Ballot writeup text was added |
2012-02-09
|
08 | (System) | Last call text was added |
2012-02-09
|
08 | David Harrington | Ballot writeup text changed |
2012-02-09
|
08 | David Harrington | Ballot writeup text changed |
2012-01-23
|
08 | David Harrington | State changed to AD Evaluation from AD Evaluation::External Party. |
2011-10-21
|
08 | David Harrington | State changed to AD Evaluation::External Party from Publication Requested::External Party. |
2011-10-18
|
08 | David Harrington | Request for Early review by TSVDIR is assigned to James Polk |
2011-10-18
|
08 | David Harrington | Request for Early review by TSVDIR is assigned to James Polk |
2011-10-18
|
08 | David Harrington | State changed to Publication Requested::External Party from Publication Requested. TSVDIR review requested - James Polk |
2011-10-10
|
08 | Cindy Morgan | 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 … 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 |
2011-10-10
|
08 | Cindy Morgan | Draft added in state Publication Requested |
2011-10-10
|
08 | Cindy Morgan | [Note]: 'Scott Bradner (sob@harvard.edu) is the document shephed.' added |
2011-08-18
|
08 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-08.txt |
2011-07-30
|
07 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-07.txt |
2011-07-10
|
06 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-06.txt |
2011-05-21
|
05 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-05.txt |
2011-01-11
|
04 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-04.txt |
2010-07-12
|
03 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-03.txt |
2010-03-09
|
02 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-02.txt |
2010-02-10
|
01 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-01.txt |
2010-01-02
|
08 | (System) | Document has expired |
2009-07-01
|
00 | (System) | New version available: draft-ietf-pcn-3-in-1-encoding-00.txt |