Skip to main content

Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-08

Yes

(Alia Atlas)
(Deborah Brungard)

No Objection

(Alissa Cooper)
(Ben Campbell)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Spencer Dawkins)
(Stephen Farrell)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Alia Atlas Former IESG member
Yes
Yes (for -07) Unknown

                            
Deborah Brungard Former IESG member
Yes
Yes (for -07) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2016-10-25 for -07) Unknown
This document mostly presents application scenarios, which (by reference) serve as motivation for draft-ietf-pce-stateful-pce.  However, there are a couple of places (in Section 4) where the operation defined in draft-ietf-pce-stateful-pce is used as part of the considerations.  For example (from 4.1):

   Stateless and stateful PCEs can co-exist in the same network and be
   in charge of path computation of different types.  To solve the
   problem of distinguishing between the two types of PCEs, either
   discovery or configuration may be used.  The capability negotiation
   in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
   address is configured on the PCC.

I see a circular dependency between this document and draft-ietf-pce-stateful-pce, where the considerations here are expected to motivate the extensions, but the specific extensions are used to discuss “generic issues with stateful PCE deployments”.

Given that draft-ietf-pce-stateful-pce is a Normative Reference, I would rather see this document come back for IESG Evaluation with/after draft-ietf-pce-stateful-pce.  Note that draft-ietf-pce-stateful-pce is still (AFAICT) under consideration in the WG.


I am not making this comment a DISCUSS because I don’t think that it raises to the appropriate level (as only some parts of the document seem to have the dependency), and we’ll have to wait for draft-ietf-pce-stateful-pce to be processed before publication anyway.  However, I think that the application scenarios and motivation for future extensions should be able to be described without referring to the extensions themselves — I would then like the authors, Shepherd and the responsible AD to consider whether it is possible for this document to stand on its own, or whether we need to process it with the extensions draft.  Given that draft-ietf-pce-stateful-pce is still in the WG, I think it is important for us to talk about it as this point.  I noted in the Shepherd’s writeup that this document used to be “originally included in the base stateful PCE protocol specification” (which I assume is draft-ietf-pce-stateful-pce).

To be clear: I am not opposing the publication of this document (even though the content could have been part of draft-ietf-pce-stateful-pce), I just think that in the current form it should be processed/published *with* draft-ietf-pce-stateful-pce.


[Mechanisms from I-D.ietf-pce-stateful-sync-optimizations and I-D.ietf-pce-pce-initiated-lsp are also mentioned in similar ways, and those drafts are also in process in the WG.  I’m focusing on draft-ietf-pce-stateful-pce above just to make the point.]
Ben Campbell Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-10-26 for -07) Unknown
I agree with Alvaro's comment. To me one important question here is if section 4 (Deployment Considerations) should be moved back into the stateful pce spec?!
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Unknown