Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-09-18
|
21 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-08-04
|
21 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-08-02
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-06-28
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-06-27
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-06-26
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-06-26
|
21 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2017-06-23
|
21 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2017-06-23
|
21 | (System) | RFC Editor state changed to EDIT |
2017-06-23
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-06-23
|
21 | (System) | Announcement was received by RFC Editor |
2017-06-23
|
21 | (System) | IANA Action state changed to In Progress |
2017-06-23
|
21 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2017-06-23
|
21 | Amy Vezza | IESG has approved the document |
2017-06-23
|
21 | Amy Vezza | Closed "Approve" ballot |
2017-06-22
|
21 | Warren Kumari | [Ballot comment] [ I simply copied Joel's No Objection position ] |
2017-06-22
|
21 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-06-21
|
21 | Amy Vezza | Ballot writeup was changed |
2017-06-21
|
21 | Deborah Brungard | Ballot approval text was changed |
2017-06-20
|
21 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-21.txt |
2017-06-20
|
21 | (System) | New version approved |
2017-06-20
|
21 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei , Edward Crabbe , Robert Varga , Jan Medved |
2017-06-20
|
21 | Ina Minei | Uploaded new revision |
2017-06-19
|
20 | Jonathan Hardwick | New version available: draft-ietf-pce-stateful-pce-20.txt |
2017-06-19
|
20 | (System) | New version approved |
2017-06-19
|
20 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei , Edward Crabbe , Robert Varga , Jan Medved |
2017-06-19
|
20 | Jonathan Hardwick | Uploaded new revision |
2017-05-17
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-05-17
|
19 | Jonathan Hardwick | New version available: draft-ietf-pce-stateful-pce-19.txt |
2017-05-17
|
19 | (System) | New version approved |
2017-05-17
|
19 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei , Edward Crabbe , Robert Varga , Jan Medved |
2017-05-17
|
19 | Jonathan Hardwick | Uploaded new revision |
2017-03-23
|
18 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2017-03-16
|
18 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2017-03-16
|
18 | Stephen Farrell | [Ballot comment] In 10.1, some references seem to be needed to say how to do that authentication and encryption. IIUC, that's a work in progress, … [Ballot comment] In 10.1, some references seem to be needed to say how to do that authentication and encryption. IIUC, that's a work in progress, or is that right? If so, when's it likely to be done and usable? |
2017-03-16
|
18 | Stephen Farrell | Ballot comment text updated for Stephen Farrell |
2017-03-16
|
18 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2017-03-16
|
18 | Benoît Claise | [Ballot comment] Below is Lionel's OPS DIR review. I've pointed out some "issues" that might not be real issues for people involved in PCE but … [Ballot comment] Below is Lionel's OPS DIR review. I've pointed out some "issues" that might not be real issues for people involved in PCE but that could be at least clarified for readers of this document. Detailed comments are provided below. Regards, Lionel ******************** 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, PCEP Speaker. This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State Database. [LM] I didn't find a clear definition of the LSP state, except through the definition of the LSP State database in ietf-pce-stateful-pce-app, i.e. The second is the LSP State Database (LSP-DB), in which a PCE stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth/resource usage, switching types and LSP constraints. As this document heavily relies on this LSP state concept, it could be useful to (re-)define it in this document or to find a correct reference for it. 3.2. Objectives The objectives for the protocol extensions to support stateful PCE described in this document are as follows: [...] o Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time. A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation. A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. [LM] I'm assuming that the PCE returning the delegation has also to notify the PCC. If so, maybe: "the If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCE about the revocation." [LM] the bullet point could be then splitted into two bullets, one for PCC, one for PCE. 5.4. Capability Advertisement During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of stateful PCEP extensions. A PCEP Speaker includes the "Stateful PCE Capability" TLV, described in Section 7.1.1, in the OPEN Object to advertise its support for PCEP stateful extensions. The Stateful Capability TLV includes the 'LSP Update' Flag that indicates whether the PCEP Speaker supports LSP parameter updates. The presence of the Stateful PCE Capability TLV in PCC's OPEN Object indicates that the PCC is willing to send LSP State Reports whenever LSP parameters or operational status changes. The presence of the Stateful PCE Capability TLV in PCE's OPEN message indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes. [LM] is it "willing/interested for" or just a capability indication? It is not the same thing from a procedure point of view. The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message. If the PCEP Speaker on the PCC supports the extensions of this draft but did not advertise this capability, then upon receipt of PCUpd message from the PCE, it MUST generate a PCErr with error-type 19 (Invalid Operation), error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised)(see Section 8.5) and it SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this draft but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with error- type 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if active stateful PCE capability was not advertised) (see Section 8.5) and it SHOULD terminate the PCEP session. [LM] why the recommendation for closing the session if an explicit error is sent back? The session could remain open i.e. except stateful PCEP extensions,everything else would be fine. If the session termination is the right thing to do, as we are in a clear error case (as the PCEP speaker should not send the report or the update), the SHOULD should probably be a MUST hee. [LM] Is there any reason to use a specific error in such a case? The PCE could just behave as a PCE not supporting the feature. Why is it important for the supporting PCEP speaker to make the difference? The generic behavior described in RFC5440 is not enough? [LM] active/passive mode are not advertized in PCEP. s/if active stateful PCE capability was not advertised/if stateful PCE capability was not advertised >From RFC5440: "6.9. Reception of Unknown Messages A PCEP implementation that receives an unrecognized PCEP message MUST send a PCErr message with Error-value=2 (capability not supported). If a PCC/PCE receives unrecognized messages at a rate equal or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message". A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session." [LM] If it is the case, the error handling would be the same between a PCEP speaker supporting the feature but not advertizing it and a PCEP speaker not supporting the feature. And it would not be possible possible to use the specific error responses to infer the capability supported by the other node. Note that even if the update capability has not been advertised, a PCE can still accept LSP Status Reports from a PCC and build and maintain an up to date view of the state of the PCC's LSPs. [LM] I don't undersand. Is it not in contradiction with "If the PCEP Speaker on the PCE supports the extensions of this draft but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with error- type 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if active stateful PCE capability was not advertised) (see Section 8.5) and it SHOULD terminate the PCEP session." Or does it mean that there is another way than PCRpt message for the PCC to send LSP status reports to the PCE? [LM] In this section, it is not described how non-supporting PCEP speaker will hanlded the new TLV. It could be said that unrecognized TLVs will be ignored (as per RFC5440) and OPEN messages will be handled as per RFC5440 (if the comment above is accepted). [LM] Would it be useful to discover (using another TLV) whether the PCE is an active/passive stateful PCE, as in IGP-based capabilities discovery mechanism? 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. [...] Note that while active and passive stateful PCE capabilities may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisements. [LM] As said above, an as stated in section 5.4: "The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message." What is the real added-value of this IGP-based mechanism? Only to be able to identify active PCE/passive PCE mode? 5.6. State Synchronization [LM] "State" could be misleading. "LSP State Sync" would be more approriate/accurate I think. The purpose of State Synchronization is to provide a checkpoint-in- time state replica of a PCC's LSP state in a PCE. State Synchronization is performed immediately after the Initialization phase ([RFC5440]). During State Synchronization, a PCC first takes a snapshot of the state of its LSPs state, then sends the snapshot to a PCE in a sequence of LSP State Reports. Each LSP State Report sent during State Synchronization has the SYNC Flag in the LSP Object set to 1. The set of LSPs for which state is synchronized with a PCE is determined by advertised stateful PCEP capabilities and PCC's local configuration (see more details in Section 9.1). [LM] It seems that : "The set of LSPs for which state is synchronized" should be: "The set of LSPs for which state is to be synchronized" [LM] I don't see how the "advertised stateful PCEP capabilities" have an effect on the set of LSP to synchronize. The capabilities adv is only used to discover stateful PCE capabilities and see if the related PCEP extensions can be used. The identification of the LSPs to synchronize seems to be only based on policies configured in the PCC. The end of synchronization marker is a PCRpt message with the SYNC Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path. [LM] What is the reason for the use of "SHOULD" here, instead of "MUST"? If the PCC has no state to synchronize, it SHOULD only send the end of synchronization marker. [LM] Is it when there is no active LSP? If it is, it could be useful to clarify it. And it is maybe not so related to the text just before. It could be clarified in a separate paragraph. A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. This is to allow the PCE to get the best possible view of the network before it starts computing new paths. [LM] it is obviously assumed that this requirement is true for PCC/PCE explicitly advertizing support of stateful PCE capability. If the PCC encounters a problem which prevents it from completing the state transfer, it MUST send a PCErr message with error-type 20 (LSP State Synchronization Error) and error-value 5 (indicating an internal PCC error) to the PCE and terminate the session. [LM] s/state transfer/LSP state synchornization 5.7.1. Delegating an LSP A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP State Report to 1. If the PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0. If the PCE accepts the LSP Delegation, it MUST set the Delegate flag to 1 when it sends an LSP Update Request for the delegated LSP (note that this may occur at a later time). The PCE MAY also immediately acknowledge a delegation by sending an empty LSP Update Request which has the Delegate flag set to 1. [LM] if the delegation is not aceepted by the PCE, I assume that the PCC should not set the Delegate flag in subsequent LSP state report. If it is, this could be clarified somewhere in this section. [..] Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP Status Report sent to the PCE. [LM] s/each LSP Status Report/each LSP State Report for this LSP. 5.7.2.1. Explicit Revocation When a PCC decides that a PCE is no longer permitted to modify an LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke an LSP delegation at any time during the LSP's life time. A PCC revoking an LSP delegation MAY immediately clear the LSP state provided by the PCE, but to avoid traffic loss, it SHOULD do so in a make-before-break fashion. [LM] After PCE delegation revocation, is there really a requirement for LSP state clean-up? The revocation is used to remove the authorization of LSP state update to the PCE but I don't see why the PCC would clear LSP state after revocation. The LSP state can be updated using operator-defined default parameters, right? If the PCC has received but not yet acted on PCUpd messages from the PCE for the LSP whose delegation is being revoked, then it SHOULD ignore these PCUpd messages when processing the message queue. All effects of all messages for which processing started before the revocation took place MUST be allowed to complete and the result MUST be given the same treatment as any LSP that had been previously delegated to the PCE (e.g. the state MAY be immediately cleared). [LM] If I correctly understood the text above, after revocation of the PCE delegation, - any PCUpd should be rejected and not ignored - the LSP state(s) that was delegated to the PCE cannot be changed until all the messages in the message queue have been processed. If I'm correct, the text above could be clarified. Any further PCUpd messages from the PCE are handled according to the PCUpd procedures described in this document. [LM] Not understood. Further PCUpd "will result in the PCC sending a PCErr message" as said after the figure. 5.7.2.2. Revocation on Redelegation Timeout When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait the time interval specified in Redelegation Timeout Interval before revoking LSP delegations to that PCE and attempting to redelegate LSPs to an alternate PCE. If a PCEP session with the original PCE can be reestablished before the Redelegation Timeout Interval timer expires, LSP delegations to the PCE remain intact. [LM] In case of PCEP session interruption, is there a requirement for the PCE to update delegated LSP states in order to ensure the synchronization between states in the PCE and in the PCC? Likewise, when a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait for the State Timeout Interval before flushing any LSP state associated with that PCE. [LM] it should be clarified that the "flushing" applies only if there is no other PCE. Otherwise, see section 5.7.4 Note that the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE, for example if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation. [LM] Not sure to understand. Is it "if a PCC is not connected to any OTHER active stateful PCE or if no OTHER connected active stateful PCE accepts the delegation? In this case, the PCC MUST flush any LSP state set by the PCE upon expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors. This operation SHOULD be done in a make-before-break fashion. [LM] I think it is important to make the distinction between PCC with only one PCE and PCC with N PCE. The "Note that" could be put in a separate section. The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval and MAY be set to infinity (meaning that until the PCC specifically takes action to change the parameters set by the PCE, they will remain intact). [LM] reading "the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE" could be understood as STI timer < RTI timer. And here, it is stated STI timer >= RTI timer. Depending on the clarification on the previous comment, this text could be also clarified (or not) 5.7.3. Returning a Delegation In order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request sent to the PCC. A PCE that no longer wishes to update an LSP's parameters SHOULD return the LSP delegation back to the PCC by sending an empty LSP Update Request which has the Delegate flag set to 0. If a PCC receives an LSP Update Request with the Delegate flag set to 0 (whether the LSP Update Request is empty or not), it MUST treat this as a delegation return. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |---PCRpt, Delegate=1--->| LSP delegated | . | | . | | . | |<--PCUpd, Delegate=0----| Delegation returned | | |---PCRpt, Delegate=0--->| No delegation for LSP | | Figure 6: Returning a Delegation If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation), the LSP delegation on the PCC will time out within a configurable Redelegation Timeout Interval and the PCC MUST flush any LSP state set by a PCE at the expiration of the State Timeout Interval. [LM] same comment: is it "for example, if a PCC is not connected to any OTHER active stateful PCE or if no OTHER connected active stateful PCE accepts the delegation"? [LM] "the PCC MUST flush any LSP state set" should be completed by "and revert to operator-defined default parameters or behaviors", right? 5.7.5. Redelegation on PCE Failure [...] If the PCE crashes but recovers within the Redelegation Timeout, both the delegation state and the LSP state are kept intact. [LM] "Recover" here seems to be associated with the PCEP session (as linked to the Redelegation Timeout), not with the LSP states maintained by the PCE. [LM] How can the PCC be ensured that the PCE has not been impacted by the stop/restart and that LSP states are intact? Is there any need for a sanity check? If the PCE crashes but does not recover within the Redelegation Timeout, the delegation state is returned to the PCC. If the PCC can redelegate the LSPs to another PCE, and that PCE accepts the delegations, there will be no change in LSP state. If the PCC cannot redelegate the LSPs to another PCE, then upon expiration of the State Timeout Interval, the state set by the PCE is flushed, which may cause change in the LSP state. [LM] the last sentence is difficult to understand. How to understand "flush the state MAY cause change in the LSP state"? It would like talking about two different states in the PCC. [LM] about "flushed", should we add "and revert to operator-defined default parameters or behaviors"? [...] If there is a standby PCE, the Redelegation Timeout may be set to 0 through policy on the PCC, causing the LSPs to be redelegated immediately to the PCC, which can delegate them immediately to the standby PCE. Assuming the State Timeout Interval is greater than the Redelegation Timeout, and assuming the standby PCE takes similar decisions as the failed PCE, the LSP state will be kept intact. [LM] the first "assuming" is not an assumption but a requirement, according to "The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval" 5.8.1. Passive Stateful PCE Path Computation Request/Response +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | 1) Path computation |----- PCReq message --->| request sent to | |2) Path computation PCE | | request received, | | path computed | | |<---- PCRep message ----|3) Computed paths | (Positive reply) | sent to the PCC | (Negative reply) | 4) LSP Status change| | event | | | | 5) LSP Status Report|----- PCRpt message --->| sent to all | . | stateful PCEs | . | | . | 6) Repeat for each |----- PCRpt message --->| LSP status change| | | | Figure 7: Passive Stateful PCE Path Computation Request/Response [LM] in the figure, please use "state" instead of "status" 7.1. OPEN Object This document defines one new optional TLVs for use in the OPEN Object. s/one new optional TLVs/one new optional TLV 7.2. SRP Object The SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt and PCErr messages. The SRP object is used to correlate between update requests sent by the PCE and the error reports and state reports sent by the PCC. [LM] Should we add the following text at the end of the section? "Optional TLVs may be included within the SRP object body. The specification of such TLVs is outside the scope of this document." 7.3. LSP Object [...] TLVs that may be included in the LSP Object are described in the following sections. [LM] I think that it is possible to add extra optional TLV, not defined in this document. This should be clarified if I'm correct. |
2017-03-16
|
18 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-03-16
|
18 | Lionel Morand | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Lionel Morand. Sent review to list. |
2017-03-15
|
18 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2017-03-15
|
18 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-03-15
|
18 | Jari Arkko | [Ballot comment] Joel Halpern's Gen-ART review caused some discussion, which probably should be reflected in the final document. |
2017-03-15
|
18 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2017-03-15
|
18 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-03-15
|
18 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-03-14
|
18 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-03-14
|
18 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-03-14
|
18 | Mirja Kühlewind | [Ballot comment] Minor comment: The U flag in the STATEFUL-PCE-CAPABILITY TLV is probably not necessary as the presents of this TVL already indicates that updates … [Ballot comment] Minor comment: The U flag in the STATEFUL-PCE-CAPABILITY TLV is probably not necessary as the presents of this TVL already indicates that updates are supported; however not an issue. |
2017-03-14
|
18 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-03-13
|
18 | Alvaro Retana | [Ballot comment] 1. Maybe it's just me, but what is the Symbolic Path Name used for? There is a mapping to the PLSP-ID, and the … [Ballot comment] 1. Maybe it's just me, but what is the Symbolic Path Name used for? There is a mapping to the PLSP-ID, and the required lifetime may be different, but I don't see where the use is explained (or why it's even needed). Also, is there any expectation to the length or character set? Given that the "symbolic path name MAY be specified by an operator in a PCC's configuration", I'm guessing it has to be something than can be printed...but there are no specifics. 2. In 9.2: "PCEP session configuration and information in the PCEP MIB module SHOULD be extended to include advertised stateful capabilities...". Ok, but I think the "SHOULD" is out of place. s/SHOULD/should |
2017-03-13
|
18 | Alvaro Retana | Ballot comment text updated for Alvaro Retana |
2017-03-13
|
18 | Alvaro Retana | [Ballot comment] 1. Maybe it's just me, but what is the Symbolic Path Name used for? There is a mapping to the PLSP-ID, and the … [Ballot comment] 1. Maybe it's just me, but what is the Symbolic Path Name used for? There is a mapping to the PLSP-ID, and the required lifetime may be different, but I don't see where the use is explained (or why it's even needed). Also, is there any expectation to the length or character set? Given that the "symbolic path name MAY be specified by an operator in a PCC's configuration", I'm guessing it has to be something than can be printed...but there are no specifics. 2. In 9.2: "PCEP session configuration and information in the PCEP MIB module SHOULD be extended to include advertised stateful capabilities..." Ok, but I think the "SHOULD" is out of place. s/SHOULD/should |
2017-03-13
|
18 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-03-07
|
18 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-03-07
|
18 | Deborah Brungard | Ballot has been issued |
2017-03-07
|
18 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-03-07
|
18 | Deborah Brungard | Created "Approve" ballot |
2017-03-07
|
18 | Deborah Brungard | Ballot writeup was changed |
2017-02-28
|
18 | Min Ye | Closed request for Last Call review by RTGDIR with state 'Withdrawn' |
2017-02-28
|
18 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-02-23
|
18 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2017-02-23
|
18 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-pce-stateful-pce-18.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-pce-stateful-pce-18.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are nine actions which we must complete. First, in the Path Computation Element (PCE) Capability Flags subregistry in the Open Shortest Path First v2 (OSPFv2) registry located at: https://www.iana.org/assignments/ospfv2-parameters/ the TEMPORARY registrations for bits 11 and 12 will be made permanent and the reference will be changed to [ RFC-to-be ]. Second, in the PCEP Messages subregistry in the Path Computation Element in the Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ the TEMPORARY registrations for values 10 and 11 will be made permanent and the reference will be changed to [ RFC-to-be ]. Third, in the PCEP Objects subregistry also in the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ the TEMPORARY registrations for Object-Class values 32 and 33 will be made permanent and the reference will be changed to [ RFC-to-be ]. Fourth, a new registry is to be created called the LSP Object Flag Field registry. The new registry will be a subregistry of the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ The new registry will be managed via Standards Action as defined in RFC 5226. There are initial registrations in the new registry as follows: Bit Description Reference --------+---------------------+-------------- 0-4 Reserved [ RFC-to-be ] 5-7 Operational (3 bits) [ RFC-to-be ] 8 Administrative [ RFC-to-be ] 9 Remove [ RFC-to-be ] 10 SYNC [ RFC-to-be ] 11 Delegate [ RFC-to-be ] Fifth, in the PCEP-ERROR Object Error Types and Values subregistry of the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ The following TEMPORARY Error-type/Error-value combinations will be made permanent and the reference will be changed to [ RFC-to-be ]: Error type: 6; Error-value: 8 Error type: 6; Error-value: 9 Error type: 6; Error-value: 10 Error type: 6; Error-value: 11 Error type: 19; Error-value: 1 Error type: 19; Error-value: 2 Error type: 19; Error-value: 3 Error type: 19; Error-value: 5 Error type: 20; Error-value: 1 Error type: 20; Error-value: 5 Sixth, in the Notification Object subregistry also in the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ The TEMPORARY registration for Notification-Type 4 and its associated Notification-values will be made permanent and the reference will be changed to [ RFC-to-be ]. Seventh, in the PCEP TLV Type Indicators subregistry also in the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ the following TEMPORARY registrations will be made permanent and the references will be changed to [ RFC-to-be ]: Values: 16, 17, 18, 19, 20 and 21. Eighth, a new registry is to be created called the STATEFUL-PCE-CAPABILITY TLV Flag Field registry. The new registry will be a subregistry of the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ The new registry will be managed via Standards Action as defined in RFC 5226. There are initial registrations in the new registry as follows: Bit Description Reference ----+-------------------------------+-------------- 31 LSP-UPDATE-CAPABILITY [ RFC-to-be ] Ninth, a new registry is to be created called the LSP-ERROR-CODE TLV Error Code Field registry. The new registry will be a subregistry of the Path Computation Element Protocol (PCEP) Numbers registry located at: https://www.iana.org/assignments/pcep/ The new registry will be managed via Standards Action as defined in RFC 5226. There are initial registrations in the new registry as follows: Value Meaning Reference -----------+--------------------------------------+-------------- 1 Unknown reason [ RFC-to-be ] 2 Limit reached for PCE-controlled LSPs [ RFC-to-be ] 3 Too many pending LSP update requests [ RFC-to-be ] 4 Unacceptable parameters [ RFC-to-be ] 5 Internal error [ RFC-to-be ] 6 LSP administratively brought down [ RFC-to-be ] 7 LSP preempted [ RFC-to-be ] 8 RSVP signaling error [ RFC-to-be ] The IANA Services Operator understands that these nine actions are the only ones required to be completed upon approval of [ RFC-to-be ]. 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 only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-02-21
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Susan Hares |
2017-02-21
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Susan Hares |
2017-02-20
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Hannes Gredler |
2017-02-20
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Hannes Gredler |
2017-02-16
|
18 | Joel Halpern | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Joel Halpern. Sent review to list. |
2017-02-16
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2017-02-16
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2017-02-15
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2017-02-15
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2017-02-15
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
2017-02-15
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
2017-02-14
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Les Ginsberg |
2017-02-14
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Les Ginsberg |
2017-02-14
|
18 | Min Ye | Requested Last Call review by RTGDIR |
2017-02-14
|
18 | Min Ye | Closed request for Telechat review by RTGDIR with state 'No Response' |
2017-02-14
|
18 | Min Ye | Request for Telechat review by RTGDIR is assigned to Danny McPherson |
2017-02-14
|
18 | Min Ye | Request for Telechat review by RTGDIR is assigned to Danny McPherson |
2017-02-14
|
18 | Min Ye | Request for Telechat review by RTGDIR is assigned to Les Ginsberg |
2017-02-14
|
18 | Min Ye | Request for Telechat review by RTGDIR is assigned to Les Ginsberg |
2017-02-14
|
18 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-02-14
|
18 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: db3546@att.com, "Julien Meuric" , pce@ietf.org, pce-chairs@ietf.org, draft-ietf-pce-stateful-pce@ietf.org, … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: db3546@att.com, "Julien Meuric" , pce@ietf.org, pce-chairs@ietf.org, draft-ietf-pce-stateful-pce@ietf.org, julien.meuric@orange.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PCEP Extensions for Stateful PCE) to Proposed Standard The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCEP Extensions for Stateful PCE' 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 ietf@ietf.org mailing lists by 2017-02-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 The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2045/ https://datatracker.ietf.org/ipr/2046/ |
2017-02-14
|
18 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-02-14
|
18 | Deborah Brungard | Placed on agenda for telechat - 2017-03-16 |
2017-02-14
|
18 | Deborah Brungard | Last call was requested |
2017-02-14
|
18 | Deborah Brungard | Ballot approval text was generated |
2017-02-14
|
18 | Deborah Brungard | Ballot writeup was generated |
2017-02-14
|
18 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2017-02-14
|
18 | Deborah Brungard | Last call announcement was generated |
2016-12-28
|
18 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2016-12-09
|
18 | Jonathan Hardwick | Request for Telechat review by RTGDIR is assigned to Danny McPherson |
2016-12-09
|
18 | Jonathan Hardwick | Request for Telechat review by RTGDIR is assigned to Danny McPherson |
2016-12-09
|
18 | Jonathan Hardwick | Requested Telechat review by RTGDIR |
2016-12-05
|
18 | Julien Meuric | 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 … 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 24 February 2012. (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? Defines 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 The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. Working Group Summary The document already has a long history. It started with squatting some codepoints, which resulted in publishing RFC 7470, a.k.a. "RFC 7150 bis". Some changes have been heavily argued, mainly because of some reluctance to update existing implementations, but this version reflects a WG consensus. Document Quality Are there existing implementations of the protocol? There are several implementations, including one open source (OpenDaylight). Have a significant number of vendors indicated their plan to implement the specification? Yes, even more than plans. 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? Some updates have been triggered by a couple of operators, thanks to some interoperability testing between several implementations. If there was a MIB 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? N/A 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 review triggered some updates and left time for interoperability feedback, resulting in some clarifications. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Only at first review, tied to early implementations; fixes have been incorporated since. (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. Usual Routing Directorate's review is expected. (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. A couple of protocol messages/objects include some redundancy inherited from early implementations. They have been discussed and the WG can live with them. (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. IPR disclosure exists. No public discussion has happened, but licensing terms are only defensive. (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? The document triggered various discussions and can be considered a consensus of the WG as a whole. (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.) No threat, discussions remained reasonable. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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, 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? No. (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. No. (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. 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 5226). IANA section looks fine and has already been used to request early allocation. (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. No identified expert review. (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, etc. None. |
2016-12-05
|
18 | Julien Meuric | Responsible AD changed to Deborah Brungard |
2016-12-05
|
18 | Julien Meuric | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-12-05
|
18 | Julien Meuric | IESG state changed to Publication Requested |
2016-12-05
|
18 | Julien Meuric | IESG process started in state Publication Requested |
2016-12-05
|
18 | Julien Meuric | Changed consensus to Yes from Unknown |
2016-12-05
|
18 | Julien Meuric | Intended Status changed to Proposed Standard from None |
2016-12-05
|
18 | Julien Meuric | Changed document writeup |
2016-12-02
|
18 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-18.txt |
2016-12-02
|
18 | (System) | New version approved |
2016-12-02
|
18 | (System) | Request for posting confirmation emailed to previous authors: "Robert Varga" , "Ina Minei" , "Edward Crabbe" , "Jan Medved" |
2016-12-02
|
18 | Ina Minei | Uploaded new revision |
2016-11-29
|
17 | Julien Meuric | Changed document writeup |
2016-11-21
|
17 | Julien Meuric | Waiting for IPR check feedback |
2016-11-21
|
17 | Julien Meuric | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2016-11-21
|
17 | Julien Meuric | Notification list changed to "Julien Meuric" <julien.meuric@orange.com> |
2016-11-21
|
17 | Julien Meuric | Document shepherd changed to Julien Meuric |
2016-11-16
|
17 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-17.txt |
2016-11-16
|
17 | (System) | New version approved |
2016-11-16
|
17 | (System) | Request for posting confirmation emailed to previous authors: "Robert Varga" , "Ina Minei" , "Edward Crabbe" , "Jan Medved" |
2016-11-16
|
17 | Ina Minei | Uploaded new revision |
2016-09-01
|
16 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-16.txt |
2016-07-18
|
15 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-15.txt |
2016-03-20
|
14 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-14.txt |
2015-12-02
|
13 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-13.txt |
2015-10-19
|
12 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-12.txt |
2015-04-20
|
11 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-11.txt |
2014-10-26
|
10 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-10.txt |
2014-06-24
|
09 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-09.txt |
2014-02-14
|
08 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-08.txt |
2013-10-08
|
07 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-07.txt |
2013-08-20
|
06 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-06.txt |
2013-07-01
|
05 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-05.txt |
2013-05-10
|
04 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-04.txt |
2013-04-01
|
(System) | Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-pce-stateful-pce-03 | |
2013-03-22
|
03 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-03.txt |
2012-10-15
|
02 | Ina Minei | New version available: draft-ietf-pce-stateful-pce-02.txt |
2012-07-15
|
01 | Jan Medved | New version available: draft-ietf-pce-stateful-pce-01.txt |
2012-02-28
|
00 | Jan Medved | New version available: draft-ietf-pce-stateful-pce-00.txt |