PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
draft-ietf-pce-pce-initiated-lsp-11

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

Deborah Brungard Yes

Ben Campbell No Objection

Benoit Claise No Objection

Spencer Dawkins (was Discuss) No Objection

Comment (2017-10-09)
Thanks for considering my Discuss.

Previous comments follow - I didn't check for these in the new version.

In this text,

  The State Timeout Interval timer ensures that a PCE crash does not
   result in automatic and immediate disruption for the services using
   PCE-initiated LSPs.  PCE-initiated LSPs are not removed immediately
   upon PCE failure.  Instead, they are cleaned up on the expiration of
   this timer.  This allows for network cleanup without manual
   intervention.  The PCC SHOULD support removal of PCE-initiated LSPs
   as one of the behaviors applied on expiration of the State Timeout
   Interval timer.  The behavior SHOULD be picked based on local policy,
   and can result either in LSP removal, or in reverting to operator-
   defined default parameters.

I found myself wondering why “The PCC SHOULD support removal of PCE-initiated LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say something about the effects of not supporting this, in order to help implementers make an informed decision about whether to support it.

In the same text, I found myself wondering if there were other alternatives to local policy for the last SHOULD, which is, of course, the last stop on the way to asking why this isn’t a MUST …

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2017-08-25 for -10)
1) I'm wondering why this spec is not part of I-D.ietf-pce-stateful-pce as it is also not published yet...?

2) I-D.ietf-pce-stateful-sync-optimizations should also be a normative references, given a flag is used in section 4.1 and a TLV is used in section 5.3.2 that are defined in that draft.

3) sec 5.4: "A PLSP-ID of zero removes all LSPs that were initiated by the PCE." and 
   "If the PLSP-ID specified in the PCInitiate message was not created by a PCE.."
  -> This means that the PCC must remember which LSP was created by which PCE at instantiation time. This could be stated more explicitly.

Terry Manderson No Objection

Kathleen Moriarty No Objection

Eric Rescorla No Objection

Comment (2017-08-30 for -10)
Document: draft-ietf-pce-pce-initiated-lsp-10.txt

Note: I reviewed this document on my experimental Phabricator instance.
You can see the comments inline at:

  https://mozphab-ietf.devsvcdev.mozaws.net/D20


It may just be my unfamiliarity with this system, but it's not clear
to me what the security model is here for the delegation. As I
understand this document the PCC just tells the PCE that it has
delegated the LSP to it, and then the PCE can make the LSP via the
normal procedures. But what is it that tells the rest of the system
that the PCC is allowed to manage that LSP. I didn't get that out of
this document or out of a cursory look at RFC 8051.


INLINE COMMENTS
Line 162
   A possible use case is a software-driven network, where applications
   request network resources and paths from the network infrastructure.
NIT: isn't the term here "software-defined network"


Line 218
   all state related to the LSP and sends a PCRpt for the removed state.
   See details in Section 5.4.
A diagram would sure help here.


Line 263
   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.
As I understand this text, you are merely adding a new code point to flags. I'm not sure it's necessary to reproduce the PDU, but if you do, you should clarify that th only change you are making is adding a new field. Perhaps on line 249 "It is reproduced here with the addition of the new I bit"


Line 278
   and the LSP objects, and MAY contain other objects, as discussed
   later in this section.
Is the syntax here supposed to be ABNF? If so, you need a citation to the syntax".


Line 337
      create an LSP.  If set to 1, it indicates a request to remove an
      LSP.
I have the same comment here about repeating PDU.


Line 436
   The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included
   here for easy reference.
This is good text, and is what I would encourage the other places you replicate PDUs from other documents.

Alvaro Retana No Objection

Comment (2017-08-30 for -10)
Just some minor comments:

(1) Section 3.2

   This document defines a new PCEP message, the LSP Initiate Request
   (PCInitiate) message, which a PCE can send to a PCE to request the
   initiaton or deletion of an LSP. 

s/...PCE can send to a PCE.../...PCE can send to a PCC...


(2) Section 5.3: "The source address MAY be either specified or left up to the PCC decision using the 0.0.0.0 value."  These seem to be the only two possible options, so s/MAY/MUST.


(3) Also from Section 5.3: "...the END-POINTS object MAY be included to explicitly convey the destination...For LSPs to be setup by other means, the END-POINTS object MAY be omitted..."

You already wrote that "other setup methods are outside the scope".  Also, not including the END-POINTS object is not an indication of other types of LSPs, as its use is optional to start with.  Take out the last sentence.

Adam Roach No Objection

Comment (2017-08-29 for -10)
Section 5.1 defines the PCInititate Message, and is generally pretty good about indicating where its component elements come from; however, it's missing pointers to <LSP>, <END-POINTS>, and <ERO>. I think you want to add: "<LSP>, <END-POINTS>, and <ERO> are defined in [RFC5440]".

Section 5.3 indicates that an indication that the PCC is supposed to pick the source address is signaled by using a source address of "0.0.0.0" -- presumably, if the destination is an IPv6 address, this would instead use "::", right? Please add text that addresses the IPv6 case.

I'm pretty certain that [I-D.ietf-pce-stateful-sync-optimizations] is a normative reference. Even though its use is optional, this document contains normative statements regarding its mechanism. See <https://www.ietf.org/iesg/statement/normative-informative.html> for guidance, and "Note 1" of that statement in particular.