Skip to main content

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