Hierarchical Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-hpce-15

[Ballot comment]
Thank you for addressing my Discuss point!

I would consider including the conclusion from our discussion about what
would happen if a PCEP speaker does not support stateful H-PCE but the peer
assumes it does, perhaps in an operational considerations section, but this does
not rise to a Discuss-level point.  For convenience, this was discussed as:

% I further did a mental exercise for PCC -> C-PCE -> P-PCE and assumed             
% all support stateful and H-PCE extension but what happens when any                 
% PCEP speaker does not support stateful H-PCE but the peer assumes that             
% it does. On further PCEP message exchange, the messages may not get               
% further propagated and thus at worse would not lead to the stateful               
% H-PCE based 'parent' control of the LSP. This is something any peer               
% should be prepared for anyways.

[Ballot comment]
Thank you for addressing my Discuss point!

I would consider including the conclusion from our discussion about what
would happen if a PCEP speaker does not support stateful H-PCE but the peer
assumes it does, perhaps in an operational considerations section.  For convenience,
this was discussed as:

% I further did a mental exercise for PCC -> C-PCE -> P-PCE and assumed             
% all support stateful and H-PCE extension but what happens when any                 
% PCEP speaker does not support stateful H-PCE but the peer assumes that             
% it does. On further PCEP message exchange, the messages may not get               
% further propagated and thus at worse would not lead to the stateful               
% H-PCE based 'parent' control of the LSP. This is something any peer               
% should be prepared for anyways.

[Ballot discuss]
I think this should be pretty easy to resolve, though I'm not sure what
the right way to do so it.

Section 3 says:

  [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE Capability TLV
  that is used in the Open message to advertise the H-PCE capability.
  [RFC8231] defines the Stateful PCE Capability TLV used in the Open
  message to indicate stateful support.  The presence of both TLVs in
  an Open message indicates the support for stateful H-PCE operations
  as described in this document.

There is no normative reference relationship (in either direction)
between draft-ietf-pce-hierarchy-extension and this document; I think
that the use of the capability TLV to imply both sets of functionality
implies some sort of normative relationship; we wouldn't want version
skew between documents to induce breaking changes.  In particular, an
implementation that already supports RFC 8231 and is implementing the
hierarchy extensions would need to know to look at this document *and
implement it*, or would unknowingly be noncompliant with this document
and fail to interoperate with a peer that is compliant with this
document.

[Ballot comment]
Abstract

                        This information may then be considered when
  computing new traffic engineered LSPs, and for associated and
  dependent LSPs, received from Path Computation Clients (PCCs). [...]

nit: I'm not sure how to parse this sentence.  The best thing I can come
up with is that "when computing new traffic engineered LSPs" and "for
associated [...]" are two separate cases, which each could independently
consider the information in question.  The first one makes sense, but
for the second I'm left trying to parse "this information may then be
considered for associated and dependent LSPs, received from PCCs", and
it's not really clear what considering the PCE is going to do if it just
sits there with information from the LSP-DB and information from PCCs (and
not doing anything with the information).

  The Hierarchical Path Computation Element (H-PCE) architecture,
  provides an architecture to allow the optimum sequence of
  [...]

nit: no comma here.

Also, three paragraphs may be pushing the bounds of an abstract in RFC
style.

Section 1.1

  path based on the domain connectivity information.  A Child PCE
  (C-PCE) may be responsible for a single domain or multiple domains,
  it is used to compute the intra-domain path based on its domain
  topology information.

nit: comma splice

  This document presents general considerations for stateful PCEs, and
  not Stateless PCEs, in the hierarchical PCE architecture.  In
  particular, the behavior changes and additions to the existing
  stateful PCE mechanisms (including PCE-initiated LSP setup and active
  PCE usage) in the context of networks using the H-PCE architecture.

nit: should "active PCE usage" read "active stateful PCE usage"?

Section 1.2

  The inter-domain LSP could be set up using the end-to-end signaling
  as described in [RFC6805]. Additionally a per-domain stitched LSP

Should I be reading this "could be set up using" as "this document
describes how to set [the LSP] up using"?

Section 1.2.2

  Different signaling methods for inter-domain RSVP-TE signaling are
  identified in [RFC4726].  Contiguous LSPs are achieved using the

nit: are the two "signaling"s redundant?

  In case of a stateful P-PCE, the stateful P-PCE has to be aware of
  the inter-domain LSPs for it to consider them during path
  computation. For example, a domain diverse path from another LSP.

nit: this last sentence is a sentence fragment.

  In this document, for the Contiguous LSP, the above interactions are
  only between the ingress domain C-PCE and the P-PCE. The use of
  stateful operations for an inter-domain LSP between the
  transit/egress domain C-PCEs towards the P-PCE is out of scope of
  this document.

nit: I suggest rewording to avoid the ambiguity of "towards" as applying
to the inter-domain LSP vs. the use of stateful operations.

Section 3

  in the topology).  The P-PCE has no information about the content of
  the child domains.  Each child domain has at least one PCE capable of

nit: we could potentially reword this in light of the remarks made about
ACTN previously.

  computing paths across the domain.  These PCEs are known as C-PCEs
  and have a direct relationship with the P-PCE.  The P-PCE builds the

It might be good to forward-reference where we talk about this
relationship in more detail.  (And, er, have more detail about the
relationship than we currently do.)

  and have a direct relationship with the P-PCE.  The P-PCE builds the
  domain topology map either via direct configuration (allowing network
  policy to also be applied) or from learned information received from
  each C-PCE.

Policy cannot be applied to information learned at runtime?

  LSP State Report (EC-EP):  a child stateful PCE sends an LSP state
      report to a Parent Stateful PCE whenever the state of a LSP
      changes.

With respect to "whenever the state of a LSP changes", is there a
possibility of a state-change that is visible to the C-PCE but does not
affect anything that the P-PCE knows about?  Is the state report still
expected to be generated in such cases?

  object to identify the Ingress (PCC). The PLSP-ID used in the
  forwarded PCRpt by the C-PCE to P-PCE is same as the original one
  used by the PCC.

I couldn't quickly find an authoritative definition of what the PLSP-ID
is; I see some discussion in RFC 8231 for the LSP Object, but am not
sure if there is prior usage.

Section 3.1

  paths.  Each C-PCE computes a set of candidate path segments across
  its domain and sends the results to the P-PCE. The P-PCE uses this
  information to select path segments and concatenate them to derive
  the optimal end-to-end inter-domain path.  The end-to-end path is
  then sent to the C-PCE that received the initial path request, and
  this C-PCE passes the path on to the PCC that issued the original
  request.

This is basically the same language as in RFC 6805, so I don't really
expect changing it to be the right thing to do, but I'm confused about
how the P-PCE is getting "candidate" segments from the C-PCEs but only
has to tell the head-end which path got picked.  Are the other C-PCEs
supposed to find out which of the candidates got used somehow?

Section 3.2

  a PCUpd message.  For LSP delegated to the P-PCE via the child PCE,
  the P-PCE can use the same PCUpd message to request change to the C-
  PCE (the Ingress domain PCE), the PCE further propagates the update
  request to the PCC.

nit: comma splice

Section 4

I expect this to not be the case, but just to check: is there a
possibility for differing levels of authorization for different PCCs,
e.g., where PCC A is allowed to request LSPs within the domain and to
any other domain, but PCC B is not allowed to request LSPs to/through a
subset of domain peers, and PCC C is only allowed to request LSPs within
the local domain?

As Roman mentions, we don't have a picture of what "full security" means
for child/parent communications.

  Thus it is RECOMMENDED to secure the PCEP session (between the P-PCE
  and the C-PCE) using either Transport Layer Security (TLS) [RFC8253]
  per the recommendations and best current practices in [RFC7525] or
  TCP Authentication Option (TCP-AO) [RFC5925].

It's not entirely clear to me that we need to call out TCP-AO here.
Partially since, as Stephen noted in the secdir review, it doesn't seem
to be implemented/deployed much, but also since RFC 8231 does call out
that it recommends TLS for confidentiality protection, which TCP-AO does
not provide.  There don't seem to be specific threats enumerated there
that the confidentiality protects against, so I am not making a strong
recommendation to remove TCP-AO from this text, but I'd like to better
understand why it was added.

  In case of TLS, due care needs to be taken while exposing the
  parameters of the X.509 certificate, such as subjectAltName:otherName
  which is set to Speaker Entity Identifier [RFC8232] as per [RFC8253],
  to ensure uniqueness and avoid any mismatch.

I'm not entirely sure which "mismatch" we would be concerned about.
And just to check: there aren't expected to be any privacy-like
considerations for exposing the speaker entity identifier to a peer in a
different domain, right?

Section 5.7

I'm not sure how appropriate it is to fully delegate (e.g.) propagation
of errors to draft-ietf-pce-enhanced-errors (which is not even a
normative reference!) -- it seems important to describe some expectation
of the error handling either in this document or in a normative
reference thereof.

Section 9.2

I think RFCs 5925, 7525, and 8253 should be normative, and RFC 7525 can
be cited as BCP 195.

[Ballot discuss]
** Section 4.  Per “The security considerations listed in [RFC8231], [RFC6805] and [RFC5440] apply to this document as well. As per [RFC6805], it is expected that the parent PCE will require all child PCEs to use full security when communicating with the parent.”, the references make sense, thanks for making them.  My concern is in the definition of “use full security”.  I can see those words come from RFC6805, however, I can't find where that set of practices is defined.  Can this please be clarified.

[Ballot comment]
** Section 4.  Per the recommendation to use TLS _or_ TCP-AO. 
-- I take the point from the SECDIR (thanks Stephen Farrell) about the (lack of) deployment of AO.  My caution would be that TLS and TCP-AO provide different security mechanism and therefore imbue different security properties and this should be noted. (i.e., this isn’t a choice between like options)

-- As an editorial nit, it would be worth saying that guidance for implementing using TLS with PCEP can be found in RFC8232.

** Editorial Nits:
Title.  Is the period at the end of the title necessary?

[Ballot comment]
Hi,

thank you for this document. I only have nit type comments:

s/hierarchy of stateful PCEs play a crucial role/hierarchy of stateful PCEs plays a crucial role/

  The ability to compute shortest constrained TE LSPs
not sure what you mean by "shortest constrained"

s/the MDSC decompose/the MDSC decomposes/

  Different signaling methods for inter-domain RSVP-TE signaling
s/methods/options/

s/the PCE further propagates/the C-PCE further propagates/

[Ballot comment]
Thanks for this document.  I have only editorial suggestions (albeit, a lot of them).  There's no need to reply in any detail; just please consider adopting these suggestions.  Thanks.

— Abstract —

  computing new traffic engineered LSPs, and for associated and

Need a hyphen in “traffic-engineered”.

— Section 1.1 —

  This document presents general considerations for stateful PCEs, and
  not Stateless PCEs, in the hierarchical PCE architecture.  In
  particular, the behavior changes and additions to the existing
  stateful PCE mechanisms (including PCE-initiated LSP setup and active
  PCE usage) in the context of networks using the H-PCE architecture.

The second “sentence” is not a complete sentence.  One way to fix that is by changing “In particular,” to “It focuses on”.

  stitching Per Domain LSPs.

Throughout, “Per-Domain” needs a hyphen.

— Section 1.2 —

In the title, “Use Cases” should *not* be hyphenated (it’s a noun, and not being used as a modifier).  There’s also an instance of this in Section 3.

  As per [RFC6805], in the hierarchical PCE architecture, a P-PCE

The second comma doesn’t belong.

  It could also be a change in topology at the P-PCE
  such as inter-domain link status change.

You could take that extra comma and put it here, after “P-PCE”.

  Additionally a per-domain stitched LSP

And then make a copy of that comma and put it after “Additionally”.

  setup, whereas Section 3.3.1 describe the per-domain stitching.

“describes”

— Section 1.2.1 —

  support the function of multi domain coordination via hierarchy,

Hyphenate “multi-domain”, or make it one word (“multidomain”).

  Virtual Network (VN) requirements before requesting for the VN to be
  provisioned.

That sounds odd using “for” and “to be”.  It should be “…requesting that the VN be provisioned.”

  P-PCE and C-PCEs. When the CNC requests for VN provisioning, the MDSC

Remove “for”.

  decompose this request into multiple inter-domain LSP provisioning

“decomposes”

— Section 1.2.2 —

  In case of a stateful P-PCE, the stateful P-PCE has to be aware of

You don’t have to say “stateful P-PCE” twice.  You can either remove the word “stateful” the second time, or (better, I think) simply remove the first clause and say, “A stateful P-PCE has to…”

  For example, a domain diverse path from another LSP.

That’s not a sentence; please make it one or merge it into an adjacent sentence (I can’t figure out the right way to do that from the text you have).

  The other LSP could be
  an associated LSP (such as protection) or an unrelated LSP whose

I don’t understand the use of “protection” here; can you clarify?

— Section 1.2.3 —

  Similarly, a P-PCE could also request for delegation if it needs to

Remove “for”.

— Section 3 —

  All PCE types herein (i.e., EC-EP or EP-EC) are assumed to

It should be “and”, not “or”, and I suggest removing the “i.e.” and just saying “(EC-EP and EP-EC)”.

  A number of interactions are expected in the Hierarchical Stateful
  PCE architecture, these include:

This is called a “comma splice”.  Make it a period instead (and have “These” start a new sentence).  Alternatively, change “these include” to “including”.

  Note that this hierarchy is recursive and thus a Label Switching
  Router (LSR), as a PCC could delegate the control to a PCE, which may
  delegate to its parent, which may further delegate it to its parent
  (if it exist or needed). Similarly update operations could also be
  applied recursively.

This has a number of problems, so let me just fix it here:

NEW
  Note that this hierarchy is recursive, so a Label Switching Router
  (LSR), as a PCC, could delegate control to a PCE, which may in turn
  delegate to its parent, which may further delegate to its parent
  (if it exists). Similarly, update operations can also be applied
  recursively.
END

  an Open message indicates the support for stateful H-PCE operations
  as described in this document.

Remove “as”.

  procedures to minimise computational loops.

“minimize” — if you use British spelling you need to be consistent about it, and you’re otherwise using American spelling throughout the document.

— Section 3.1 —

  It then sends computation requests to the C-
  PCEs responsible for each of the domains on the candidate domain

I think it’s better not to allow “C-PCE” (and other such terms) to be hyphen-split across lines.

  A local policy at
  C-PCE may dictate which LSPs to be reported to the P-PCE.

“to be” is not right here.  I’d make it “are” (or “should be”).

  State synchronization mechanism as described in [RFC8231] and
  [RFC8232] are applicable

“mechanisms”

  We use the sample hierarchical domain topology example from [RFC6805]

I’d remove “sample”, because “example” covers it.  Or remove “example”… either way.

  following additional steps are added for stateful PCE to be executed
  at the end:

Comma after “PCE”, please.

— Section 3.2 —

  As per [RFC8051], Delegation is an operation to grant a PCE,
  temporary rights

Remove the comma after “PCE”.

  The C-PCE may further choose to delegate to P-PCE based
  on a local policy.

To any P-PCE?  Or “to its P-PCE”?

  The PCRpt message with "D" (delegate) flag is
  sent from C-PCE to P-PCE.

‘with the “D” (delegate) flag’ (add ‘the’)

  For LSP delegated to the P-PCE via the child PCE,
  the P-PCE can use the same PCUpd message to request change to the C-
  PCE (the Ingress domain PCE), the PCE further propagates the update
  request to the PCC.

Again, multiple issues:

NEW
  For an LSP delegated to a P-PCE via the child PCE, the P-PCE
  can use the same PCUpd message to request a change to the C-PCE
  (the Ingress domain PCE).  The PCE further propagates the update
  request to the PCC.
END

— Section 3.3 —

  In case of inter-domain LSP in
  Hierarchical PCE architecture, the initiation operations can be
  carried out at the P-PCE.  In which case after P-PCE finishes the E2E
  path computation, it can send the PCInitiate message to the C-PCE

There are articles missing here.  I think it should be “an inter-domain LSP” and “after the P-PCE finishes”.

  The following steps are performed, for PCE initiated operations,

Remove the first comma and hyphenate “PCE-initiated”.

— Section 3.3.1 —

  operation is possible, where multiple intra-domain LSPs are initiated
  in each domain which are further stitched to form an E2E LSP.

Needs a comma after “each domain”.

  The following steps are performed, for the Per Domain stitched LSP

Remove the comma.

  Note that each per-domain LSP can be setup in parallel.

“set up”, two words.

— Section 5.1 —

  If a parent PCE receives report from an unauthorized child

“a report”

  All mechanism as described in
  [RFC8231] and [RFC8281] continue to apply.

“mechanisms”

— Section 5.2 —

  The PCEP YANG module
  [I-D.ietf-pce-pcep-yang] may be extended to include details for
  stateful H-PCE deployment and operation, exact attributes to be
  modeled is out of scope for this document.

Who will (or may) extend it, and when might that happen?
And change the comma to a period and capitalize “Exact” (another comma splice).

— Section 6.3 —

  Along with the confidentiality during path
  computation, the child PCE could also conceal the path information, a
  C-PCE may replace a path segment with a path-key [RFC5520],
  effectively hiding the content of a segment of a path.

Combination of problems:

NEW
  Along with maintaining confidentiality during path
  computation, the child PCE could also conceal the path information.
  A C-PCE may replace a path segment with a path-key [RFC5520],
  effectively hiding the content of a segment of a path.
END

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

The IANA Functions Operator has reviewed draft-ietf-pce-stateful-hpce-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-28):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, Adrian Farrel , draft-ietf-pce-stateful-hpce@ietf.org, pce@ietf.org, pce-chairs@ietf.org, adrian@olddog.co.uk
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Hierarchical Stateful Path Computation Element (PCE).) to Informational RFC


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Hierarchical Stateful Path Computation
Element (PCE).'
  as Informational RFC

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 2019-08-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 Stateful Path Computation Element (PCE) maintains information on
  the current network state, including: computed Label Switched Path
  (LSPs), reserved resources within the network, and pending path
  computation requests. This information may then be considered when
  computing new traffic engineered LSPs, and for associated and
  dependent LSPs, received from Path Computation Clients (PCCs). The
  Path computation response from a PCE is helpful for the PCC to
  gracefully establish the computed LSP.

  The Hierarchical Path Computation Element (H-PCE) architecture,
  provides an architecture to allow the optimum sequence of
  inter-connected domains to be selected, and network policy to be
  applied if applicable, via the use of a hierarchical relationship
  between PCEs.

  Combining the capabilities of Stateful PCE and the Hierarchical PCE
  would be advantageous. This document describes general considerations
  and use cases for the deployment of Stateful, and not Stateless, PCEs
  using the Hierarchical PCE architecture.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-hpce/ballot/


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

Request for posting confirmation emailed to previous authors: Young Lee , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Oscar de Dios , pce-chairs@ietf.org, Jongyoon Shin

Document shepherd write-up

The PCE Working Group requests the publication of draft-ietf-pce-stateful-hpce as an IETF Stream RFC.

> (1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Publication as an Informational RFC is requested.

This is appropriate because the document is an applicability statement that does not define any protocol elements. This status is indicated in the header on the title page.

> (2) Please provide a Document Announcement Write-Up.
>
> Technical Summary:

A Stateful Path Computation Element (PCE) maintains information on the current network state including existing Traffic Engineered (TE) Label Switched Path (LSPs).  This information may be considered when computing path for new TE LSPs.

The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of inter-connected domains to be selected for a multi-domain TE LSP.

This document describes general considerations and use cases for the deployment of Stateful PCEs using the Hierarchical PCE architecture.

> Working Group Summary:

The working group process was "steady." The document was adopted two years ago and has progressed slowly with small updates and direction from the WG mainly off-list.

As an applicability statement, the WG supported the idea of the work (the adoption poll attracted support from ten non-authors), but didn't seem to put in much effort to advance the work, preferring to watch the authors write the text.

WG last call had several constructive comments of support that included reasoning, and also a couple of helpful reviews.

But there were no issues with consensus.

> Document Quality:

There are several research implementations of stateful hierarchical PCEs confessed to separately by two network operators, an equipment vendor, and a few universities. As such, this document provides a base reference for how to put the concepts together in a meaningful way.

No special reviewing was necessary.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (db3546@att.com) is the Responsible Area Director

> (3) Briefly describe the review of this document that was performed by the Document Shepherd.

I reviewed this document at revision -06 coincident with WG last call. I had a large number of comments that were a mixture of editorial and clarification, and the authors have addressed these over the last three revisions.

The document could still be better-written, but I think energy to polish it has run out.

There are currently six author names on the front page, and I am working with the authors to agree that this number will be reduced to five or fewer during the IETF last call review period.

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

No. The relevant specialists in this topic are either authors or have reviewed the document.

> (5) Do portions of the document need review from a particular or from broader perspective.

None needed.

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

No such concerns.

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

A specific poll was sent to all authors and contributors and answered on the working group mailing list.
This serves in addition to the boilerplate text.

> (8) Has an IPR disclosure been filed that references this document?

No IPR has been disclosed.

> (9) How solid is the WG consensus behind this document?

The consensus is reasonable. There is no dissent, and a small number (in addition to the authors) expressed strong support. It is a relatively small working group, and so this represents a passable level of support.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No threats, no discontent.

> (11) Identify any ID nits the Document Shepherd has found in this document.

idnits runs clean

> (12) Describe how the document meets any required formal review criteria

No such criteria

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

They have

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

All normative references are in-force published RFCs.

> (15) Are there downward normative references (see RFC 3967)?

No downrefs.

> (16) Will publication of this document change the status of any existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section.

No IANA action is requested.
A suitable null IANA Considerations section is present.

> (18) List any new IANA registries that require Expert Review for future allocations.

None

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language.

No such language, no such checks.

Document shepherd write-up

The PCE Working Group requests the publication of draft-ietf-pce-stateful-hpce as an IETF Stream RFC.

> (1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Publication as an Informational RFC is requested.

This is appropriate because the document is an applicability statement that does not define any protocol elements. This status is indicated in the header on the title page.

> (2) Please provide a Document Announcement Write-Up.
>
> Technical Summary:

A Stateful Path Computation Element (PCE) maintains information on the current network state including existing Traffic Engineered (TE) Label Switched Path (LSPs).  This information may be considered when computing path for new TE LSPs.

The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of inter-connected domains to be selected for a multi-domain TE LSP.

This document describes general considerations and use cases for the deployment of Stateful PCEs using the Hierarchical PCE architecture.

> Working Group Summary:

The working group process was "steady." The document was adopted two years ago and has progressed slowly with small updates and direction from the WG mainly off-list.

As an applicability statement, the WG supported the idea of the work (the adoption poll attracted support from ten non-authors), but didn't seem to put in much effort to advance the work, preferring to watch the authors write the text.

WG last call had several constructive comments of support that included reasoning, and also a couple of helpful reviews.

But there were no issues with consensus.

> Document Quality:

There are several research implementations of stateful hierarchical PCEs confessed to separately by two network operators, an equipment vendor, and a few universities. As such, this document provides a base reference for how to put the concepts together in a meaningful way.

No special reviewing was necessary.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (db3546@att.com) is the Responsible Area Director

> (3) Briefly describe the review of this document that was performed by the Document Shepherd.

I reviewed this document at revision -06 coincident with WG last call. I had a large number of comments that were a mixture of editorial and clarification, and the authors have addressed these over the last three revisions.

The document could still be better-written, but I think energy to polish it has run out.

There are currently six author names on the front page, and I am working with the authors to agree that this number will be reduced to five or fewer during the IETF last call review period.

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

No. The relevant specialists in this topic are either authors or have reviewed the document.

> (5) Do portions of the document need review from a particular or from broader perspective.

None needed.

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

No such concerns.

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

A specific poll was sent to all authors and contributors and answered on the working group mailing list.
This serves in addition to the boilerplate text.

> (8) Has an IPR disclosure been filed that references this document?

No IPR has been disclosed.

> (9) How solid is the WG consensus behind this document?

The consensus is reasonable. There is no dissent, and a small number (in addition to the authors) expressed strong support. It is a relatively small working group, and so this represents a passable level of support.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No threats, no discontent.

> (11) Identify any ID nits the Document Shepherd has found in this document.

idnits runs clean

> (12) Describe how the document meets any required formal review criteria

No such criteria

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

They have

> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

All normative references are in-force published RFCs.

> (15) Are there downward normative references (see RFC 3967)?

No downrefs.

> (16) Will publication of this document change the status of any existing RFCs?

No.

> (17) Describe the Document Shepherd's review of the IANA considerations section.

No IANA action is requested.
A suitable null IANA Considerations section is present.

> (18) List any new IANA registries that require Expert Review for future allocations.

None

> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language.

No such language, no such checks.

Request for posting confirmation emailed to previous authors: Dhruv Dhody , Jongyoon Shin , Daniel King , Oscar de Dios , Daniele Ceccarelli , pce-chairs@ietf.org, Young Lee

Request for posting confirmation emailed to previous authors: Daniele Ceccarelli , Dhruv Dhody , Daniel King , Oscar de Dios , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Dhruv Dhody , Jongyoon Shin , Daniel King , Daniele Ceccarelli , pce-chairs@ietf.org, Young Lee

Request for posting confirmation emailed to previous authors: Oscar de Dios , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Daniele Ceccarelli , Dhruv Dhody , Daniel King , Young Lee , Jongyoon Shin

Request for posting confirmation emailed to previous authors: Oscar de Dios , Dhruv Dhody , Jongyoon Shin , Daniel King , Daniele Ceccarelli , Young Lee