PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model
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
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.