Skip to main content

Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
RFC 8408

Revision differences

Document history

Date Rev. By Action
2018-07-25
10 (System) IANA registries were updated to include RFC8408
2018-07-24
10 (System)
Received changes through RFC Editor sync (created alias RFC 8408, changed title to 'Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages', changed …
Received changes through RFC Editor sync (created alias RFC 8408, changed title to 'Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages', changed abstract to 'A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints.  Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol.  However, other TE path setup methods are possible within the PCE architecture.  This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-07-24, changed IESG state to RFC Published)
2018-07-24
10 (System) RFC published
2018-07-24
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-06-19
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-06-12
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-05-14
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-05-14
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-05-14
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-05-11
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-05-11
10 (System) RFC Editor state changed to EDIT
2018-05-11
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-05-11
10 (System) Announcement was received by RFC Editor
2018-05-11
10 (System) IANA Action state changed to In Progress
2018-05-11
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2018-05-11
10 Amy Vezza IESG has approved the document
2018-05-11
10 Amy Vezza Closed "Approve" ballot
2018-05-11
10 Amy Vezza Ballot approval text was generated
2018-05-11
10 Amy Vezza Ballot writeup was changed
2018-05-11
10 Deborah Brungard Ballot approval text was changed
2018-05-04
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-04
10 Jonathan Hardwick New version available: draft-ietf-pce-lsp-setup-type-10.txt
2018-05-04
10 (System) New version approved
2018-05-04
10 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Jonathan Hardwick , Robert Varga , Siva Sivabalan , Jeff Tantsura
2018-05-04
10 Jonathan Hardwick Uploaded new revision
2018-04-05
09 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-04-05
09 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2018-04-05
09 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'Overtaken by Events'
2018-04-04
09 Warren Kumari
[Ballot discuss]
Ignas balloted NoObj; I'll be the baddie.

Section 6.  Manageability Considerations says:
---
Each document that introduces a new path setup type to …
[Ballot discuss]
Ignas balloted NoObj; I'll be the baddie.

Section 6.  Manageability Considerations says:
---
Each document that introduces a new path setup type to PCEP must
  include a manageability section.  The manageability section must
  explain how operators can manage PCEP with the new path setup type.
  It must address the following questions, which are generally
  applicable when working with multiple path setup types in PCEP.

  o  What are the criteria for when devices will use the new path setup
      type in PCEP, and how can the operator control this?

  o  How can the network be migrated to the new path setup type, and
      are there any backwards compatibility issues that operators need
      to be aware of?

  o  Are paths set up using the new path setup type intended to coexist
      with other paths over the long term and, if so, how is this
      situation managed with PCEP?
----

So, I see lots of open questions, but no answers to any of these....
2018-04-04
09 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2018-04-04
09 Eric Rescorla
[Ballot comment]
Please expand RP and SRP on first use.

What is the backward compatibility story here? I.e., say I only support method X and …
[Ballot comment]
Please expand RP and SRP on first use.

What is the backward compatibility story here? I.e., say I only support method X and the peer doesn't know about this TLV at all? How will it behave?
2018-04-04
09 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-04-04
09 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-04-04
09 Sheng Jiang Assignment of request for Telechat review by OPSDIR to Sheng Jiang was rejected
2018-04-04
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Sheng Jiang
2018-04-04
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Sheng Jiang
2018-04-04
09 Ignas Bagdonas
[Ballot comment]
This is a major comment, I am not balloting DISCUSS at this time as author's intentions may have been to do the right …
[Ballot comment]
This is a major comment, I am not balloting DISCUSS at this time as author's intentions may have been to do the right thing, and it has simply slipped or not yet done.

Manageability section lists the right questions, but there are no answers to those questions. Could authors please answer the questions in section 9?

Would capabilities be augmenting the PCEP YANG model, under entity or peer branches? It does not seem that there is a need for a separate model just for this extension?
2018-04-04
09 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-04-03
09 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-04-03
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-04-03
09 Ben Campbell
[Ballot comment]
Substantive Comments:

§1.1: There are at least a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from …
[Ballot comment]
Substantive Comments:

§1.1: There are at least a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.

§7:
Doesn't this need to say something about the possible security considerations when adding new path setup types ?

Editorial Comments and Nits:

§5: "... it MUST consider that the peer suports only ...: I think perhaps "consider" should have been "assume"? Also, s/suports/supports.
2018-04-03
09 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-04-03
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-04-03
09 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-04-03
09 Mirja Kühlewind
[Ballot comment]
Mostly editorial (and I guess already flagged by Alvaro and Martin):

This sentence (in sec 3 as well as the similar sentence in …
[Ballot comment]
Mostly editorial (and I guess already flagged by Alvaro and Martin):

This sentence (in sec 3 as well as the similar sentence in sec 4) should not use normative language because that basically non-sensical:
"If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it MUST ignore the TLV in accordance with ([RFC5440])."
Should be instead:
"If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it will ignore the TLV in accordance with ([RFC5440])."
2018-04-03
09 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-04-03
09 Alexey Melnikov [Ballot comment]
People already nitpicked on definition of "reserved", so I will not :-)
2018-04-03
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-04-03
09 Martin Vigoureux
[Ballot comment]
Document says:
  If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it MUST ignore the TLV in accordance with ([ …
[Ballot comment]
Document says:
  If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
and:
  If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST
  ignore the TLV in accordance with ([RFC5440]).

I am fine with this but it does not say anything, explicitly, on what shall be the selected signalling protocol. I guess it will be RSVP-TE because I guess we treat this situation in the same way as if there had been no TLV. But since I am guessing, I feel it wouldn't hurt to be explicit.
On the assumption that my guesses are correct, what about adding, for example, the following sentence (or anything else you'd judge more appropriate):
  From a signalling protocol selection point of view, this situation is treated as if the ... TLV was absent.
2018-04-03
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-04-02
09 Spencer Dawkins
[Ballot comment]
I'll let you folks work with Benjamin on this, but I echo his concern about the level of specification covering sub-TLVs (Spencer's summary: …
[Ballot comment]
I'll let you folks work with Benjamin on this, but I echo his concern about the level of specification covering sub-TLVs (Spencer's summary: "not much specification").  As a related comment, I note that not defining any sub-TLVs in this document prevents the authors from giving any examples of what sub-TLVs might be appropriate, which would have been helpful for me in both the Abstract and Introduction.

(I usually prefer clues about whether the reader should be reading a specification or not. It would be easier for me to know whether this document is relevant to me, if I knew what kinds of sub-TLVs were envisioned, even if only a couple of examples were provided. But do the right thing, of course)
2018-04-02
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-04-02
09 Benjamin Kaduk
[Ballot comment]
I'm concerned about defining the space for optional sub-TLVs in PATH-SETUP-TYPE-CAPABILITY but
not giving much description of how future sub-TLVs would work (since …
[Ballot comment]
I'm concerned about defining the space for optional sub-TLVs in PATH-SETUP-TYPE-CAPABILITY but
not giving much description of how future sub-TLVs would work (since none are currently defined).
Is there expected to be a one-to-one mapping from PST to sub-TLV, or one-to-many, or something else?
If a given sub-TLV can be associated with more than one PST, some rules would need to be specified for
how that mapping works, what dependency there is on the order in which sub-TLVs appear in the message,
etc.  I am not balloting DISCUSS because I suspect the intent is for each sub-TLV to correspond to exactly one
PST, in which case the behavior is pretty easy.  But I would like to see more description of how this is expected
to work.

Both new TLVs have 'Reserved' fields that MUST be set to zero.  Should they be ignored on receipt (to allow
for potential future use as an extension) or can the receiver validate that they are zero?

The Security Considerations defer to RFCs 5440 and 8281, which (as the secdir review notes) is mostly okay.
RFC 5440 does have a long discussion of the value of TCP authentication, but IIUC it does not mandate that
TCP authentication be used.  That would leave open the possibility that an attacker (e.g., TCP MITM) could
generate error messages when a particular PST is used, potentially forcing the use of a different PST, and this
attacker capability seems to be new in this document.  As such, it would merit a mention in the Security Considerations.
(This attack only becomes relevant in the face of some additional weakness or flaw in a PST that makes forcing
its use advantageous to the attacker for other reasons.)
2018-04-02
09 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-04-02
09 Alvaro Retana
[Ballot comment]
(1) The Length field in S3 has no units.  I'm sure people can guess it is in bytes, from the rest of the …
[Ballot comment]
(1) The Length field in S3 has no units.  I'm sure people can guess it is in bytes, from the rest of the description, but it should be explicit.

(2) The Reserved fields "MUST be set to zero".  What happens if they're not?  Typically they are also ignored by the receiver...

(3) S3: "Each sub-TLV MUST obey the rules for TLV formatting defined in ([RFC5440]).  That is, each sub-TLV MUST be padded to a four byte alignment, and the length field of each sub-TLV MUST NOT include the padding bytes."  The first sentence is ok.  The second one tries to paraphrase what rfc5440 says -- but rfc5440 doesn't say that, it doesn't even use Normative language!  This is the text from rfc5440:

  The Length field defines the length of the value portion in bytes.
  The TLV is padded to 4-bytes alignment; padding is not included in
  the Length field (so a 3-byte value would have a length of 3, but the
  total size of the TLV would be 8 bytes).

(3a) The text in this document shouldn't use Normative language to describe what rfc5440 says and specifies.

(3b) Note that the text from rfc5440 (specifically the part about "padding is not included in the Length field") is not aligned with the description of the Length field in this document: "The TLV Length field MUST be equal to the size of the appended sub-TLVs plus the size of the PST list (rounded up to the nearest multiple of four) plus four bytes."  Rounding up includes the padding.

(4) S6: "Each document that introduces a new path setup type to PCEP must include a manageability section."  Why is a Normative "MUST" not used?

(5) rfc6123 is a Historic document.  Maybe a reference to rfc5706 is more appropriate (even in addition to rfc6123).
2018-04-02
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-03-31
09 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2018-03-29
09 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-03-29
09 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-03-29
09 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2018-03-29
09 Deborah Brungard Ballot has been issued
2018-03-29
09 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2018-03-29
09 Deborah Brungard Created "Approve" ballot
2018-03-29
09 Deborah Brungard Ballot writeup was changed
2018-03-28
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-03-27
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-03-27
09 Jonathan Hardwick New version available: draft-ietf-pce-lsp-setup-type-09.txt
2018-03-27
09 (System) New version approved
2018-03-27
09 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Jonathan Hardwick , Robert Varga , Siva Sivabalan , Jeff Tantsura
2018-03-27
09 Jonathan Hardwick Uploaded new revision
2018-03-09
08 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-03-08
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-03-08
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pce-lsp-setup-type-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pce-lsp-setup-type-08. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the existing temporary registration will be made permanent and its reference changed to [ RFC-to-be ]:

Value: 28
Description: PATH-SETUP-TYPE
Reference: [ RFC-to-be ]

Second, also in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: PATH-SETUP-TYPE-CAPABILITY
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the PCEP Path Setup Types registry. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The registration policy for the new registry will be IETF Consensus as defined by RFC 8126.

There is a single, initial registration in the new registry as follows:

Value Description Reference

0 Path is setup using the RSVP- [ RFC-to-be ]
TE signaling protocol.

IANA Question --> What is the range of values for this new registry?

Fourth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and their references changed to [ RFC-to-be ]:

Error-Type Meaning
10 Reception of an invalid object

Error-value?: Malformed object

Error-Type Meaning
21 Invalid traffic engineering path setup type

Error-value=0: Unassigned
Error-value=1: Unsupported path setup type
Error-value=2: Mismatched path setup type

IANA notes that the temporary registration for:

Error-Type Meaning
10 Reception of an invalid object

Error-value?: Malformed object

was not done by this document. However, this document is making the registration permanent.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-03-08
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery.
2018-03-01
08 Amy Vezza
The following Last Call announcement was sent out (ends 2018-03-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien …
The following Last Call announcement was sent out (ends 2018-03-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENDED Last Call:  (Conveying path setup type in PCEP messages) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Conveying path setup type in PCEP
messages'
  as 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 2018-03-28. 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


  A Path Computation Element can compute Traffic Engineering (TE) paths
  through a network that are subject to various constraints.
  Currently, TE paths are Label Switched Paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ballot/


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




2018-03-01
08 Amy Vezza Last call announcement was changed
2018-02-28
08 Dan Romascanu Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. Sent review to list.
2018-02-26
08 Roni Even Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Roni Even. Sent review to list.
2018-02-22
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-02-22
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-02-22
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2018-02-22
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2018-02-21
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2018-02-21
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2018-02-20
08 Deborah Brungard Placed on agenda for telechat - 2018-04-05
2018-02-20
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-02-20
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien …
The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Conveying path setup type in PCEP messages) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Conveying path setup type in PCEP
messages'
  as 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 2018-03-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


  A Path Computation Element can compute Traffic Engineering (TE) paths
  through a network that are subject to various constraints.
  Currently, TE paths are Label Switched Paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ballot/


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




2018-02-20
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-02-20
08 Deborah Brungard Last call was requested
2018-02-20
08 Deborah Brungard Ballot approval text was generated
2018-02-20
08 Deborah Brungard Ballot writeup was generated
2018-02-20
08 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2018-02-20
08 Deborah Brungard Last call announcement was changed
2018-01-16
08 Jonathan Hardwick New version available: draft-ietf-pce-lsp-setup-type-08.txt
2018-01-16
08 (System) New version approved
2018-01-16
08 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Jonathan Hardwick , Robert Varga , Siva Sivabalan , Jeff Tantsura
2018-01-16
08 Jonathan Hardwick Uploaded new revision
2018-01-10
07 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Daniele Ceccarelli.
2017-12-19
07 Min Ye Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli
2017-12-19
07 Min Ye Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli
2017-12-19
07 Deborah Brungard Requested Last Call review by RTGDIR
2017-12-19
07 Julien Meuric
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

It is a protocol extension.

Is this type of RFC indicated in the title page header?

Yes

(2) 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

  A Path Computation Element can compute traffic engineering paths (TE
  paths) through a network that are subject to various constraints.
  Currently, TE paths are label switched paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.

Working Group Summary

No controversy. The capability feature added after the 1st LC resulted in a significant change, agreed on the list, and a 2nd WGLC.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?

There are several PCEP implementations supporting Segment Routing, which implies the support of this I-D. The discussion on the list about backward compatible changes showed the I-D is implemented.

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?

As a shepherd, I triggered the latest changes about a missing feature.

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?

N/A

Personnel

  Who is the Document Shepherd?

Julien Meuric

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready. The latest change was the inclusion of a capability TLV, as a resolution of my main comment.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

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

It is a building block used for Segment Routing in PCEP, which has clear consensus.

(10) 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 publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

OK

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes (all being considered as normative)

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is very clear, since it really had to. It mixes existing early allocation, new request and import from another I-D in an precise manner.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2017-12-19
07 Julien Meuric Responsible AD changed to Deborah Brungard
2017-12-19
07 Julien Meuric IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-12-19
07 Julien Meuric IESG state changed to Publication Requested
2017-12-19
07 Julien Meuric IESG process started in state Publication Requested
2017-12-19
07 Julien Meuric Tag Revised I-D Needed - Issue raised by WGLC cleared.
2017-12-19
07 Julien Meuric IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2017-12-19
07 Julien Meuric Changed document writeup
2017-12-19
07 Jonathan Hardwick New version available: draft-ietf-pce-lsp-setup-type-07.txt
2017-12-19
07 (System) New version approved
2017-12-19
07 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Jonathan Hardwick , Robert Varga , Siva Sivabalan , Jeff Tantsura
2017-12-19
07 Jonathan Hardwick Uploaded new revision
2017-12-04
06 Julien Meuric Changed document writeup
2017-11-20
06 Jonathan Hardwick New version available: draft-ietf-pce-lsp-setup-type-06.txt
2017-11-20
06 (System) New version approved
2017-11-20
06 (System) Request for posting confirmation emailed to previous authors: Jonathan Hardwick , Siva Sivabalan , Ina Minei , pce-chairs@ietf.org, Jeff Tantsura , Robert Varga
2017-11-20
06 Jonathan Hardwick Uploaded new revision
2017-10-29
05 Jeff Tantsura New version available: draft-ietf-pce-lsp-setup-type-05.txt
2017-10-29
05 (System) New version approved
2017-10-29
05 (System) Request for posting confirmation emailed to previous authors: Ina Minei , Robert Varga , Jonathan Hardwick , Siva Sivabalan , Jeff Tantsura
2017-10-29
05 Jeff Tantsura Uploaded new revision
2017-10-29
04 (System) Document has expired
2017-05-16
04 Julien Meuric Notification list changed to Julien Meuric <julien.meuric@orange.com>
2017-05-16
04 Julien Meuric Document shepherd changed to Julien Meuric
2017-05-16
04 Julien Meuric Changed consensus to Yes from Unknown
2017-05-16
04 Julien Meuric Intended Status changed to Proposed Standard from None
2017-05-16
04 Julien Meuric Tag Revised I-D Needed - Issue raised by WGLC set.
2017-05-16
04 Julien Meuric IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2017-05-02
04 Julien Meuric This document now replaces draft-sivabalan-pce-lsp-setup-type instead of None
2017-05-02
04 Julien Meuric IETF WG state changed to In WG Last Call from WG Document
2017-04-27
04 Jeff Tantsura New version available: draft-ietf-pce-lsp-setup-type-04.txt
2017-04-27
04 (System) New version approved
2017-04-26
04 (System)
Request for posting confirmation emailed to previous authors: Jonathan Hardwick , Siva Sivabalan , Jeff Tantsura , Jan Medved , Ina Minei , pce-chairs@ietf.org, …
Request for posting confirmation emailed to previous authors: Jonathan Hardwick , Siva Sivabalan , Jeff Tantsura , Jan Medved , Ina Minei , pce-chairs@ietf.org, Robert Varga
2017-04-26
04 Jeff Tantsura Uploaded new revision
2015-06-23
03 Siva Sivabalan New version available: draft-ietf-pce-lsp-setup-type-03.txt
2015-04-20
02 Siva Sivabalan New version available: draft-ietf-pce-lsp-setup-type-02.txt
2015-03-09
01 Siva Sivabalan New version available: draft-ietf-pce-lsp-setup-type-01.txt
2014-10-27
00 Siva Sivabalan New version available: draft-ietf-pce-lsp-setup-type-00.txt