Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs
draft-ietf-pce-pcep-extension-for-pce-controller-14

[Ballot comment]
Thank you for the work put into this document. Thank you for addressing my previous DISCUSS points; I have cleared my previous DISCUSS points but nevertheless please upload yet-another-revised I-D before sending it to the RFC Editor.

Section 7.3.1 should use " IPv6 address: the 128-bit IPv6 link-local address of the interface." rather than " IPv6 address: A 128-bit IPv6 address of the node."

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS [kept for history] ==

-- Section 7.3.1 --
LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two addresses in this TLV while others have one one ? Also is 'local' and 'remote' really global addresses ?

== COMMENTS [kept for history] ==

A minor comment: the abstract is clear but probably a little too long for an abstract.

-- Section 7.3 --
Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section but well in the next one ?

[Ballot discuss]
Thank you for the work put into this document. I have not had time to review in details though :( but I appreciated the detailed description as well as the useful time diagrams.

Please find below one blocking DISCUSS point (which may be my bad understanding), some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 7.3.1 --
LINKLOCAL-IPV6-ID-ADDRESS TLV: I fail to understand why there are two addresses in this TLV while others have one one ? Also is 'local' and 'remote' really global addresses ?

[Ballot comment]
== COMMENTS ==

A minor comment: the abstract is clear but probably a little too long for an abstract.

-- Section 7.3 --
Just wonder why  LINKLOCAL-IPV6-ID-ADDRES is not mentioned in this section but well in the next one ?

[Ballot comment]
Hi,

Thanks for the document, I have not had time to review in detail.

The length of the abstract does stand out to me, and it might be helpful if it could be shortened.  E.g. I suspect that the first two paragraphs are probably not required in the abstract and are best covered in the introduction.

On section 10:

  A PCE or PCC implementation SHOULD allow to configure to enable/
  disable PCECC capability as a global configuration.  =>
  A PCE or PCC implementation SHOULD allow the PCECC capability
  to be enabled/disabled as part of the global configuration.

Also probably change "is enabled on the PCEP session" to "is enabled on a PCEP session"?

Regards,
Rob

[Ballot comment]
In Section 2, RFC 8283 isn't a "draft".

In Section 5.5.1:

  Once the label operations are completed, the PCE SHOULD send a PCUpd
  message to the ingress PCC.

Why "SHOULD"?  Is there another option?  Why might an implementer do something else?

The SHOULDs elsewhere in Section 5 are probably worth a second look too.

[Ballot comment]
I agree with Roman about the prospects for ensuring a solid security
baseline with what is essentially greenfield deployment.

(throughout) Is the TLV LSP-IDENTIFIER or LSP-IDENTIFIERS (with final
'S')?

Thanks to Yaron Sheffer for the secdir reviews, and to the authors for
updating in light of that review.

I note in a few places in the section-by-section comments that the
figures seem to indicate a 'D' flag in PCInitiate and PCUpd messages,
and the only D flag I see mentioned in the prose is the Delegate flag in
a PCRpt.  This seems particularly important to check and get right
(though I admit that I could just be missing something).

Section 1

  A PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/setup/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network
  devices along the path while leveraging the existing PCE technologies
  as much as possible.

nit: "each network device" singular.

Section 2

  The terminology used in this document is the same as that described
  in the draft [RFC8283].

"That RFC doesn't look like a draft to me"

Section 3

  This document also allows a case where the label space is maintained
  by the PCC itself, and the labels are allocated by the PCC, in this
  case, the PCE should request the allocation from PCC as described in
  Section 5.5.8.

nit: comma splice.

Section 4

  4.  PCEP procedures need to provide a mean to update (or clean up)
      the label-download entry to the PCC.

  5.  PCEP procedures need to provide a mean to synchronize the labels
      between the PCE and the PCC via PCEP messages.

nits: "provide a means" plural (twice); s/the label-download entry/label
entries downloaded/ (I think)

Section 5.4

  A legacy PCEP speaker (that does not recognize the PCECC Capability
  sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and
  [RFC5440].  As per [RFC8408], the legacy PCEP speaker (that does not
  support PST), it will:

Sending a PCErr for an unrecognized PST in the
PATH-SETUP-TYPE-CAPABILITY would break extensibility; the 21/1 error
type/value pair is only used in RFC 8408 when a PST is attempted to be
used in a PCRpt, PCInitiate, or PCUpd.  I think we should just say that
it ignores the PST in the PATH-SETUP-TYPE-CAPABILITY TLV.

Section 5.5.1

  An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple
  uniquely identifies the LSP in the network.  [...]

Which tuple?

Also, RFC 8231 says that the LSP-IDENTIFIERS TLV (note final 'S') must
be used for RSVP-signaled LSPs, but PCECC is not (to my knowledge)
requiring the use of RSVP.  Do we need to say anything to generalize
LSP-IDENTIFIERS for other use?

  The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C
  (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message
  to the PCE in the initial exchange.  The PCC responds with a PCRpt
  message with the status set to "GOING-UP" and carrying the assigned
  PLSP-ID (see Figure 1).  [...]

nit: "responds" feels a bit out of place here, since the first sentence
has already talked about setting flags in the PCRpt.  Switching the
order of the sentences might help, but there still wouldn't be a very
clear connection in the prose between the PCRpt and triggering
PCInitiate.

                                                              Each PCC
  further responds with the PCRpt messages including the central
  controller instruction (CCI) and the LSP objects.  The PCC responds
  with a PCRpt message to acknowledge the central controller
  instruction.

Likewise, the second "responds" here feels out of place.

                |PCC    |                              |  PCE  |
                |ingress|                              +-------+
          +------|      |                                  |
          | PCC  +-------+                                  |
          | transit| |                                      |
  +------|        | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP
  |PCC  +--------+ |                                      | Initiate

[sorry for truncation] In the PCInitiate line, what does D=1 refer to?
The only mention of a D flag I can find is that the PCC must set D=1 in
the initial PCRpt to delegate the LSP.

      |      |    |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP
      |      |    |      (UP)                            | Update

Likewise, what is the 'D=1' in PCUpd?

(Both remarks seem to apply to Figure 2 as well.)

      - The O bit is set as before (and thus not included)


            Figure 2: PCE-Initiated PCECC LSP (PCC allocation)

(It doesn't look like we currently indicate the O bit in Figure 1, so
this remark feels a little out of place.  We do indicate the O bit in
Figure 3, though.)

Section 5.5.3

  As per [RFC8281], following the removal of the Label forwarding
  instruction, the PCC MUST send a PCRpt message.  The SRP object in
  the PCRpt MUST include the SRP-ID-number from the PCInitiate message
  that triggered the removal.  The R flag in the SRP object MUST be
  set.

This text seems to indicate that the R flag is set in the SRP object in
the PCRpt, but this does not seem to be reflected in Figure 5.

Section 5.5.4

                                New CC-IDs are used to identify the
  updated instructions, the identifiers in the LSP object identify the
  existing LSP.  [...]

nit: comma splice.

      |      |    |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC
      |      |    |    SRP=S                            | LSP Update

(I remain unsure about the D flag in the PCUpd.)

Section 5.5.8

  the Label.  If the allocation is successful, the PCC MUST report via
  the PCRpt message with the CCI object.  Else, it MUST send a PCErr
  message with Error-Type = TBD5 ("PCECC failure") and Error Value =
  TBD9 ("Invalid CCI").  If the value of the Label in the CCI object is
  valid, but the PCC is unable to allocate it, it MUST send a PCErr
  message with Error-Type = TBD5 ("PCECC failure") and Error Value =
  TBD10 ("Unable to allocate the specified CCI").

I might be misreading, but this seems to say that if allocation failed
but the value of the label in the CCI object is valid, you have to send
*two* PCErr messages, one with TBD9 and one with TBD10 (there are two
MUST-level requirements that seem to both apply).  I mostly assume that
just one would suffice, so a bit of rewording might be in order.

  If the PCC wishes to withdraw or modify the previously assigned
  label, it MUST send a PCRpt message without any Label or with the
  Label containing the new value respectively in the CCI object.  The
  PCE would further trigger the removal of the central controller
  instruction as per this document.

This seems quite vague about which CCI is to be removed from where.

Section 6.1

  At most two instances of the CCI object can be included, in the case
  of transit LSR to encode both in-coming and out-going label
  forwarding instructions.  Other instances MUST be ignored for P2P
  LSP.  [...]

It's a little hard to square up "at most two instances" and "other
instances MUST be ignored", even if the former doesn't use normative
language.

Section 7.1.1

  o  L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates
      that the PCEP speaker support and willing to handle the PCECC

nits: "supports and is willing"

Section 7.3

  CC-ID:  A PCEP-specific identifier for the CCI information.  A PCE
      creates a CC-ID for each instruction, the value is unique within
      the scope of the PCE and is constant for the lifetime of a PCEP
      session.  The values 0 and 0xFFFFFFFF are reserved and MUST NOT be
      used.

In the vein of draft-gont-numeric-ids-sec-considerations, please include
some discussion on whether the uniqueness property is the only one
needed (e.g., no ordering or gap detection), as well as some analysis of
what information is leaked (including side channels) if the CC-ID is
revealed to outside parties.

My preliminary instinct is that if the value is only in scope for a
single live PCEP session (i.e., two fixed peers) and the session is
protected by TLS, there is no harm in doing sequential allocation and
that makes ensuring uniqueness easier, but there are any number of ways
in which such a trivial analysis could be flawed.

Section 7.3.1

IANA already shows IPV4-ADDRESS and IPV6-ADDRESS TLVs allocated by RFC
8779, with what appears to be identical structure to these.  Why are new
TLV types necessary?

Section 9

I agree with the secdir reviewer that it would be worthwhile to discuss
authorization as well as authentication.  In a system with the
privileged central controller, confirming that a given authenticated
entity is authorized to act as the central controller is important to
the overall security of the system (so that a compromised PCC node
cannot claim to be a PCE to other, uncompromised, PCC nodes).  This
might be done, for example, via an attribute in the PCE's X.509
certificate used for PCEPS or a local policy with a specific accept-list
of X.509 certificate.

Section 9.1

I think we should reiterate the guidance that PCCs need to check that
labels provided by the PCE are in the proper range.

  general precaution, it is RECOMMENDED that this PCEP extension be
  activated on mutually-authenticated and encrypted sessions across
  PCEs and PCCs belonging to the same administrative authority, using
  TLS [RFC8253], as per the recommendations and best current practices
  in [RFC7525].

It's probably best to cite this as BCP 195, as there is likely to be an
updated version in the next couple years.

                                [RFC8281] provides a mechanism to
  protect PCC by imposing a limit.  The same can be used for the PCECC
  operations as well.

nit: either "PCCs" or "the PCC".

Section 11.6

  IANA is requested to create a new sub-registry to manage the Flag
  field of the CCI object called "CCI Object 16-bits Flag Field".  New

Are these flags expected to be specific to the Object-Type 1 (MPLS
Label) CCI Object?  If so, perhaps the registry name should indicate
that.

Section 13.2

We generally see RFC 8126 listed as normative when used for the
registration procedures when defining a new registry.

Per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
it seems that the recommended behavior with RFCs 8253 and 7525 should
make them normative references.

[Ballot comment]
Thank you to Yaron Sheffer for the SECDIR review and the updates made as a result to improve the Security Considerations.  I endorse the revised text that minimally RECOMMENDs the use of “mutually-authenticated and encrypted sessions.”  My question is why can’t we go even further and require (use MUST) this crucial provisioning channel always be protected.  When would we NOT want to use TLS?  I appreciate that mandating the use of security primitives in routing is challenging due to a long tail of legacy investment.  However, this extension seems like a near "green field" focused on a modern, SDN architecture which seems unlikely to have less capable legacy elements.

[Ballot discuss]
[ section 7.3.1 ]

* This intended handling of the LINKLOCAL-IPV6-ID-ADDRESS TLV does not seem
  to be discussed anywhere in this document.  Should there be some text
  about it, or is this TLV left over from previous iterations of the document?

* Saying that the LINKLOCAL-IPV6-ID-ADDRESS TLV holds a pair of global IPv6
  addresses seems confusing to me.

  If the pair of global IPv6 addresses is to be considered "on link" in the
  sense that IPv6 ND can be successfully be performed on the link for both
  of these addresses, then "ONLINK" might be better than LINKLOCAL.

* Also, why are two interface IDs required?  I would have expected that only
  the outgoing interface name/ID would be of relevance to the recipient of
  a message with TLV in it?

[Ballot comment]
[[ nits ]]

[ section 4 ]

* "provide a mean" -> "provide a means", perhaps

[ section 5.5.4 ]

* "and then notify it to" -> "and then sends a notification to", or something

[Ballot comment]
(0) The fact that the procedures (§5) are presented before introducing the messages/objects (§6-7) makes reading this document harder and more complex than it has to be.  Consider changing the order or at least adding forward references in §5.

(1) §5.2:  Is there a reason for the messages from rfc8231 to be in parenthesis?

(2) §5.4: 

  The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the
  corresponding Path Setup Type being listed in the PATH-SETUP-TYPE-
  CAPABILITY TLV.  If it is present without the corresponding Path
  Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be
  ignored.

When is it ok to use the PCECC-CAPABILITY sub-TLV without the corresponding PST?  If the result is that it will be ignored, then I don't understand why the use of both is not required.

(3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check mechanism and report the status back to the PCE"  Is this (checking and reporting) specified somewhere?  Because you're using normative language, please add a reference.

A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any OAM mechanism to check the status of LSP in the Data plane and MAY further send its status in a PCRpt message to the PCE".

(4) §5.5.3: s/central controller instructions...is done/central controller instructions...are done

(5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the PCE using the PCRpt message."  When is it ok for the PCC to not allocate and/or report?  IOW, why are these actions only recommended and not required?  Note that the very next paragraph requires the behavior.

(6) §7.3/§7.3.1:  In the out-label case, "it is mandatory to encode the next-hop information".  Should this information point at a directly connected IP address/interface, or can it point at a remote next-hop (which may be resolved through a routing protocol)?  What if the expected conditions are not met?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-pcep-extension-for-pce-controller-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are seven 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/

four, new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: IPV4-ADDRESS TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: IPV6-ADDRESS TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: UNNUMBERED-IPV4-ID-ADDRESS TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: LINKLOCAL-IPV6-ID-ADDRESS TLV
Reference: [ RFC-to-be ]

Second, in the PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Meaning: PCECC-CAPABILITY
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the PCECC-CAPABILITY sub-TLV 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 registry will be managed via Standards Action as defined in RFC 8126. There are new registrations in the new registry as follows:

Bit Name Reference
------+----------------------+-------------------
31 Label [ RFC-to-be ]
0-30 Unassigned

Fourth, in the PCEP Path Setup Types registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Traffic engineering path is set up using PCECC mode
Reference: [ RFC-to-be ]

Fifth, in the PCEP Objects registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

a single, new codepoint is to be registered as follows:

Object-Class Value Name Object-Type
-----------------------+---------------+--------------
[ TBD-at-Registration ] CCI Object-Type
0 Reserved
1 MPLS Label

This registration will have a reference of [ RFC-to-be ]

Sixth, a new registry is to be created called the CCI Object 16-bits Flag Field. 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 registry will be managed via Standards Action as defined in RFC 8126. There are new registrations in the new registry as follows:

Bit Description Reference
-------------+------------------------+---------------
0-13 Unassigned [ RFC-to-be ]
14 C Bit - PCC allocation [ RFC-to-be ]
15 O Bit - Specifies label [ RFC-to-be ]
is out-label

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

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

new error-types and error values are to be registered as follows:

Error-type: 6 (Mandatory Object missing)
Error-value: [ TBD-at-Registration ]:
CCI object missing
Reference: [ RFC-to-be ]

Error-type: 10 (Reception of an invalid object)
Error-value: [ TBD-at-Registration ]:
Missing PCECC Capability sub-TLV
Reference: [ RFC-to-be ]

Error-type: 19 (Invalid operation)
Error-value: [ TBD-at-Registration ]:
Attempted PCECC operations when PCECC capability was not advertised
Reference: [ RFC-to-be ]
Error-value: [ TBD-at-Registration ]:
Stateful PCE capability was not advertised
Reference: [ RFC-to-be ]
Error-value: [ TBD-at-Registration ]:
Unknown Label
Reference: [ RFC-to-be ]

Error-type: [ TBD-at-Registration ] (PCECC failure)
Error-value: [ TBD-at-Registration ]:
Label out of range
Reference: [ RFC-to-be ]
Error-value: [ TBD-at-Registration ]:
Instruction failed
Reference: [ RFC-to-be ]
Error-value: [ TBD-at-Registration ]:
Invalid CCI
Reference: [ RFC-to-be ]
Error-value: [ TBD-at-Registration ]:
Unable to allocate the specified CCI
Reference: [ RFC-to-be ]

The IANA Functions 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

The following Last Call announcement was sent out (ends 2021-02-08):

From: The IESG
To: IETF-Announce
CC: Julien Meuric , db3546@att.com, draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org, julien.meuric@orange.com, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'PCEP Procedures and Protocol Extensions
for Using PCE as a Central
  Controller (PCECC) of LSPs'
  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
last-call@ietf.org mailing lists by 2021-02-08. 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 Path Computation Element (PCE) is a core component of Software-
  Defined Networking (SDN) systems.  It can compute optimal paths for
  traffic across a network and can also update the paths to reflect
  changes in the network or traffic demands.

  PCE was developed to derive paths for MPLS Label Switched Paths
  (LSPs), which are supplied to the head end of the LSP using the Path
  Computation Element Communication Protocol (PCEP).  But SDN has a
  broader applicability than signaled MPLS and GMPLS traffic-engineered
  (TE) networks, and the PCE may be used to determine paths in a range
  of use cases.  PCEP has been proposed as a control protocol for use
  in these environments to allow the PCE to be fully enabled as a
  central controller.

  A PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/set up/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network device
  along the path, while leveraging the existing PCE technologies as
  much as possible.

  This document specifies the procedures and PCEP extensions for using
  the PCE as the central controller.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 includes some protocol extensions.

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 PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/set up/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network device
  along the path, while leveraging the existing PCE technologies as
  much as possible.
  This document specifies the procedures and PCEP extensions for using
  the PCE as the central controller.

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?
- No particular pain point. The discussion mainly happened in the TEAS WG. Afterwards, the corresponding PCEP extensions progressed smoothly.

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, YANG 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?

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 has been carefully reviewed and looks ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
- No particular concern, even though the number of WG members who commented/reviewed is limited.

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

(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?
- This I-D is the PCE counterpart of a document from the TEAS WG. Support was there at adoption time, it narrowed to the contributors' companies at WGLC; no concern was expressed.

(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.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://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, YANG Doctor, media type, and URI type reviews.
- N/A

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

(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?
- N/A

(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.
- N/A

(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.
- The IANA sections looks consitent with the document's body.
Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
- OK
Confirm that any referenced IANA registries have been clearly identified.
- OK
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 8126).
- 2 sub-registries are created and are properly initialized.

(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 (standards action)

(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, YANG modules, etc.
- N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
- N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 includes some protocol extensions.

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 PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/set up/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network device
  along the path, while leveraging the existing PCE technologies as
  much as possible.
  This document specifies the procedures and PCEP extensions for using
  the PCE as the central controller.

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?
- No particular pain point. The discussion mainly happened in the TEAS WG. Afterwards, the corresponding PCEP extensions progressed smoothly.

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, YANG 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?

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 has been carefully reviewed and looks ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
- No particular concern, even though the number of WG members who commented/reviewed is limited.

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

(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?
- This I-D is the PCE counterpart of a document from the TEAS WG. Support was there at adoption time, it narrowed to the contributors' companies at WGLC; no concern was expressed.

(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.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://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, YANG Doctor, media type, and URI type reviews.
- N/A

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

(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?
- N/A

(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.
- N/A

(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.
- The IANA sections looks consitent with the document's body.
Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
- OK
Confirm that any referenced IANA registries have been clearly identified.
- OK
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 8126).
- 2 sub-registries are created and are properly initialized.

(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 (standards action)

(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, YANG modules, etc.
- N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
- N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 includes some protocol extensions.

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 PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/set up/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network device
  along the path, while leveraging the existing PCE technologies as
  much as possible.
  This document specifies the procedures and PCEP extensions for using
  the PCE as the central controller.

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?
- No particular pain point. The discussion mainly happened in the TEAS WG. Afterwards, the corresponding PCEP extensions progressed smoothly.

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, YANG 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?

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 has been carefully reviewed and looks ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
- No particular concern, even though the number of WG members who commented/reviewed is limited.

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

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

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

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

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

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

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

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

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

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

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

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

(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, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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 includes some protocol extensions.

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 PCE-based Central Controller (PCECC) can simplify the processing of
  a distributed control plane by blending it with elements of SDN and
  without necessarily completely replacing it.  Thus, the LSP can be
  calculated/set up/initiated and the label forwarding entries can also
  be downloaded through a centralized PCE server to each network device
  along the path, while leveraging the existing PCE technologies as
  much as possible.
  This document specifies the procedures and PCEP extensions for using
  the PCE as the central controller.

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?
No particular pain point. The discussion mainly happened in the TEAS WG. Afterwards, the corresponding PCEP extensions progressed smoothly.

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, YANG 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?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Request for posting confirmation emailed to previous authors: Zhenbin Li , Adrian Farrel , Dhruv Dhody , Satish Karunanithi , pce-chairs@ietf.org, Quintin Zhao , Chao Zhou