Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol
RFC 5455
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
02 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
02 | (System) | Notify list changed from pce-chairs@ietf.org, draft-ietf-pce-dste@ietf.org to (None) |
|
2009-03-27
|
02 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2009-03-27
|
02 | Cindy Morgan | [Note]: 'RFC 5455' added by Cindy Morgan |
|
2009-03-27
|
02 | (System) | RFC published |
|
2009-01-28
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2009-01-28
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2009-01-28
|
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2009-01-20
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2009-01-20
|
02 | (System) | IANA Action state changed to In Progress |
|
2009-01-20
|
02 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2009-01-20
|
02 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2009-01-20
|
02 | Amy Vezza | IESG has approved the document |
|
2009-01-20
|
02 | Amy Vezza | Closed "Approve" ballot |
|
2009-01-16
|
02 | (System) | Removed from agenda for telechat - 2009-01-15 |
|
2009-01-15
|
02 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Charles Clancy. |
|
2009-01-15
|
02 | Cindy Morgan | State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan |
|
2009-01-15
|
02 | David Ward | [Ballot Position Update] New position, Yes, has been recorded by David Ward |
|
2009-01-15
|
02 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
|
2009-01-15
|
02 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2009-01-15
|
02 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2009-01-14
|
02 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
|
2009-01-14
|
02 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2009-01-14
|
02 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2009-01-14
|
02 | Tim Polk | [Ballot comment] Section 3.3, paragraph 6 suggest the following rewording: OLD A PCE that recognizes the CLASSTYPE object finds that P flag is not … [Ballot comment] Section 3.3, paragraph 6 suggest the following rewording: OLD A PCE that recognizes the CLASSTYPE object finds that P flag is not set in the CLASSTYPE object, it MUST send PCE error message towards the sender with the with the error type and error value specified in [PCEP-ID]. NEW A PCE that recognizes the CLASSTYPE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send a PCE error message towards the sender with the error type and error value specified in [PCEP-ID]. |
|
2009-01-14
|
02 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2009-01-14
|
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2009-01-14
|
02 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2009-01-14
|
02 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2009-01-14
|
02 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2009-01-14
|
02 | Jari Arkko | [Ballot comment] Title and abstract spell diff-serv differently: Diff-Serv Diff-Serve which is right? |
|
2009-01-09
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2009-01-06
|
02 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
|
2009-01-06
|
02 | Ross Callon | Ballot has been issued by Ross Callon |
|
2009-01-06
|
02 | Ross Callon | Created "Approve" ballot |
|
2009-01-06
|
02 | Ross Callon | Placed on agenda for telechat - 2009-01-15 by Ross Callon |
|
2009-01-06
|
02 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon |
|
2008-12-24
|
02 | Amanda Baber | IANA comments: Action 1: Upon approval of this document, IANA will make the following assignments in the "PCEP Objects" registry at http://www.iana.org/assignments/pcep/pcep.xhtml Object Class Name … IANA comments: Action 1: Upon approval of this document, IANA will make the following assignments in the "PCEP Objects" registry at http://www.iana.org/assignments/pcep/pcep.xhtml Object Class Name Reference -------------+------------------------------------------+-------------- 22 CLASSTYPE [RFC-pce-dste-02] Object-Type 1: Class Type [RFC-pce-dste-02] 2-15: Unassigned Action 2: Upon approval of this document, IANA will make the following assignments in the "PCEP-ERROR Object Error Types and Values" registry at http://www.iana.org/assignments/pcep/pcep.xhtml Error Type Meaning Reference ----------+----------------------------------------------+--------- 12 Diff-Serv aware TE error [RFC-pce-dste-02] Error-value = 1: [RFC-pce-dste-02] Unsupported class-type Error-value = 2: [RFC-pce-dste-02] Invalid class-type Error-value = 3: [RFC-pce-dste-02] Class type and setup priority does not form a configured TE class Error-value = 4-255: Unassigned We understand the above to be the only IANA Actions for this document. |
|
2008-12-23
|
02 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2008-12-13
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charles Clancy |
|
2008-12-13
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charles Clancy |
|
2008-12-09
|
02 | Amy Vezza | Last call sent |
|
2008-12-09
|
02 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2008-12-09
|
02 | Ross Callon | State Changes to Last Call Requested from Publication Requested by Ross Callon |
|
2008-12-09
|
02 | Ross Callon | Last Call was requested by Ross Callon |
|
2008-12-09
|
02 | (System) | Ballot writeup text was added |
|
2008-12-09
|
02 | (System) | Last call text was added |
|
2008-12-09
|
02 | (System) | Ballot approval text was added |
|
2008-11-03
|
02 | Amy Vezza | Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of … Intended status : Standards Track > (1.a) Who is the Document Shepherd for this document? 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? JP Vasseur is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The I-D was well discussed when first posted and then got stable fairly quickly. > (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 concerns. > (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. 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. 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 issue specific issues. No IPR disclosures filed. > (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, the document specifies fairly straightforward protocol extensions. > (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 threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html 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? All checks made. > (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]. No downward reference. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? 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 [RFC2434]. 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? The document requests extensions to the PCEP IANA registries. The IANA section looks good. > (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? A reference to draft-farrel-rtg-common-bnf is included in the document for the BNF used in this document. [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", draft-farrel-rtg- common-bnf-07.txt, November 2008. No tool has been used for verification. > (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 > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. The Internet Draft [PCEP-ID] specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs, in compliance with [RFC4657]. Differentiated Service aware MPLS Traffic Engineering (DS-TE) addresses the fundamental requirement to be able to enforce different bandwidth constraints for different classes of traffic. It describes mechanisms to achieve per-class traffic engineering, rather than on an aggregate basis across all classes by enforcing Bandwidth Constraints (BCs) on different classes. Requirements for DS-TE and the associated protocol extensions are specified in [RFC3564] and [RFC4124] respectively. As per [RFC4657], PCEP must support traffic class-type as an MPLS TE specific constraint. However, in the present form, PCEP [PCEP-ID] does not have the capability to specify the class-type in the path computation request. In this document, we define a new PCEP object called CLASSTYPE which carries the class-type of the TE LSP in the path computation request. During path computation, a PCE uses the class-type to identify the bandwidth constraint of the TE-LSP. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? Good support and no controversy. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? No known implementation of the I-D but several mentioned that they were planning to implement the protocol extensions specifies in the document. Furthermore, the protocol extensions are very straightforward. |
|
2008-11-03
|
02 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
|
2008-11-03
|
02 | (System) | New version available: draft-ietf-pce-dste-02.txt |
|
2008-05-27
|
01 | (System) | New version available: draft-ietf-pce-dste-01.txt |
|
2007-10-23
|
00 | (System) | New version available: draft-ietf-pce-dste-00.txt |