PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE
draft-ietf-pce-stateful-pce-lsp-scheduling-27
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-11-03 |
27 | (System) | IANA registries were updated to include RFC8934 |
2020-10-31 |
27 | (System) | Received changes through RFC Editor sync (created alias RFC 8934, changed title to 'PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with … Received changes through RFC Editor sync (created alias RFC 8934, changed title to 'PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE', changed abstract to 'This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.', changed pages to 23, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-10-31, changed IESG state to RFC Published) |
2020-10-31 |
27 | (System) | RFC published |
2020-10-24 |
27 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-10-12 |
27 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-09-22 |
27 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-09-01 |
27 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-09-01 |
27 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-09-01 |
27 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-08-28 |
27 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-08-27 |
27 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2020-08-27 |
27 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Daniel Gillmor was marked no-response |
2020-08-26 |
27 | (System) | RFC Editor state changed to EDIT |
2020-08-26 |
27 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-08-26 |
27 | (System) | Announcement was received by RFC Editor |
2020-08-26 |
27 | (System) | IANA Action state changed to In Progress |
2020-08-26 |
27 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2020-08-26 |
27 | Cindy Morgan | IESG has approved the document |
2020-08-26 |
27 | Cindy Morgan | Closed "Approve" ballot |
2020-08-26 |
27 | Cindy Morgan | Ballot writeup was changed |
2020-08-26 |
27 | Deborah Brungard | Ballot approval text was changed |
2020-08-26 |
27 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-27.txt |
2020-08-26 |
27 | (System) | New version approved |
2020-08-26 |
27 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Qin WU <bill.wu@huawei.com> |
2020-08-26 |
27 | Huaimo Chen | Uploaded new revision |
2020-08-08 |
26 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-26.txt |
2020-08-08 |
26 | (System) | New version approved |
2020-08-08 |
26 | (System) | Request for posting confirmation emailed to previous authors: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com> |
2020-08-08 |
26 | Huaimo Chen | Uploaded new revision |
2020-08-07 |
25 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-25.txt |
2020-08-07 |
25 | (System) | New version approved |
2020-08-07 |
25 | (System) | Request for posting confirmation emailed to previous authors: Qin WU <bill.wu@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2020-08-07 |
25 | Huaimo Chen | Uploaded new revision |
2020-08-07 |
24 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! |
2020-08-07 |
24 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-08-07 |
24 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-24.txt |
2020-08-07 |
24 | (System) | New version approved |
2020-08-07 |
24 | (System) | Request for posting confirmation emailed to previous authors: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Qin WU <bill.wu@huawei.com> |
2020-08-07 |
24 | Huaimo Chen | Uploaded new revision |
2020-08-07 |
23 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-23.txt |
2020-08-07 |
23 | (System) | New version approved |
2020-08-07 |
23 | (System) | Request for posting confirmation emailed to previous authors: Zhuangyan <zhuangyan.zhuang@huawei.com>, Qin WU <bill.wu@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2020-08-07 |
23 | Huaimo Chen | Uploaded new revision |
2020-08-04 |
22 | Benjamin Kaduk | [Ballot discuss] Thanks for addressing my first two discuss points from the -19; it looks like the last one is still remaining (please note that … [Ballot discuss] Thanks for addressing my first two discuss points from the -19; it looks like the last one is still remaining (please note that I had a typo in my original ballot on the -19, referring to a section 3.3 when 7.3.3 was intended): Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 7.3.3 of RFC 8231. |
2020-08-04 |
22 | Benjamin Kaduk | [Ballot comment] I have some new comments after reviewing the diff from -19 to -22. (Signs indicate that processing of my previous comments is still … [Ballot comment] I have some new comments after reviewing the diff from -19 to -22. (Signs indicate that processing of my previous comments is still underway; if there's a need to refer to them they are available in the email archives and in the 'history' tab for the document in the datatracker.) Section 4.1 For a scheduled LSP crossing multiple domains from an ingress domain to an egress domain. There is a PCE responsible for each of these domains. The PCE for the ingress domain is called ingress PCE. The PCE for the egress domain is called egress PCE. The state of the LSP MUST be synchronized among these PCEs. After a path for the LSP is computed, a PCRpt message with the scheduled LSP information MUST be sent to every PCE along the path from the ingress PCE to the egress PCE. After receiving the PCRpt message, the PCE MUST update its SLSP-DB according to the scheduled LSP information. The ingress PCE acting as a PCC sends its next hop PCE the PCRpt message. After receiving the PCRpt message, the next hop PCE acting as a PCC sends its next hop PCE the PCRpt message. This continues until the egress PCE receives the PCRpt message. A bunch of nits here. How about % Additional requirements apply when a scheduled LSP crosses multiple % domains, from an ingress domain to an egress domain. There is a PCE % responsible for each of these domains. The PCE for the ingress % domain is called the ingress PCE. The PCE for the egress domain is % called the egress PCE. The state of the LSP MUST be synchronized % among all PCEs along the path. To achieve this, after a path for the % LSP is computed, a PCRpt message with the scheduled LSP information % MUST be sent to every PCE along the path from the ingress PCE to the % egress PCE. After receiving the PCRpt message, each PCE MUST update % its SLSP-DB according to the scheduled LSP information. The ingress % PCE acting as a PCC sends its next hop PCE the PCRpt message. After % receiving the PCRpt message, the next hop PCE acting as a PCC sends % its next hop PCE the PCRpt message. This continues until the egress % PCE receives the PCRpt message. Section 4.3 o The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP. Besides, it MUST send a PCRpt message with the scheduled LSP to its next hop PCE along the path of the LSP, so as to achieve the scheduling traffic engineering information synchronization. nit: I think s/Besides/Additionally/ Section 5.1 During a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. [...] Some nits here; maybe: % During the PCE session establishment phase, a PCC and PCE indicate % their ability to support LSC scheduling. [...] Section 5.2 Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its presence in the LSP object. The new text here has changed what I interpret it to mean. I interpret the text in the -22 as allowing for an LSP that includes one SCHED-LSP-ATTRIBUTE and one SCHED-PD-LSP-ATTRIBUTE TLV in the same LSP, whereas the text from the -19 seemed to indicate that if (e.g.) I had a periodic scheduling TLV then the regular SCHED-LSP-ATTRIBUTE was forbidden. After just a cursory amount of thought, it seems like there is not a useful way to interpret both TLVs at the same time, which would make this text change a regression, but I may be missing something. Section 5.2.2 STATEFUL-PCE-CAPABILITY TLV carried in open message. If the TLV is received by a peer when both bits were not set, the peer MUST ignore the TLV and generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter). (nit) English has this unfortunate property where the "not set" in "both bits were not set" can be interpreted as a synonym for "unset", which would make "both bits were not set" mean that this is describing the case where B=0 and PD=0. What we actually mean is "anything other than (B=1,PD=1)", which might be expressed as "If the TLV is received by a peer when either (or both) bit is not set". |
2020-08-04 |
22 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2020-07-13 |
22 | Benjamin Kaduk | [Ballot discuss] [edited to fix a typo in the section number, but otherwise unchanged from the original position on the -19] This being a discuss … [Ballot discuss] [edited to fix a typo in the section number, but otherwise unchanged from the original position on the -19] This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. There seems to be an internal inconsistency in Section 4.3, between "[t]he PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED" and "[t]he stateful PCE is required to update its local scheduled LSP-DB and scheduled TED". (I think the "SHOULD" one is wrong, personally.) Let's also take a closer look at the precise interdependency between the B bit and PD bit -- Section 5.1 implies that the PD bit itself cannot be set in the absence of the B bit, referring forward to Section 5.2.2, but Section 5.2.2 seems to only say that you need both the B and PD bits set in order to send SCHED-PD-LSP-ATTRIBUTE. Bits being set as a prerequisite for sending the TLV is a subtly different condition than having the one bit itself depend on the other, with correspondingly different error handling. Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 7.3.3 of RFC 8231. |
2020-07-13 |
22 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2020-07-13 |
22 | Benjamin Kaduk | [Ballot discuss] This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. … [Ballot discuss] This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. There seems to be an internal inconsistency in Section 4.3, between "[t]he PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED" and "[t]he stateful PCE is required to update its local scheduled LSP-DB and scheduled TED". (I think the "SHOULD" one is wrong, personally.) Let's also take a closer look at the precise interdependency between the B bit and PD bit -- Section 5.1 implies that the PD bit itself cannot be set in the absence of the B bit, referring forward to Section 5.2.2, but Section 5.2.2 seems to only say that you need both the B and PD bits set in order to send SCHED-PD-LSP-ATTRIBUTE. Bits being set as a prerequisite for sending the TLV is a subtly different condition than having the one bit itself depend on the other, with correspondingly different error handling. Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 7.3.3 of RFC 8231. |
2020-07-13 |
22 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2020-07-13 |
22 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-22.txt |
2020-07-13 |
22 | (System) | New version approved |
2020-07-13 |
22 | (System) | Request for posting confirmation emailed to previous authors: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Qin WU <bill.wu@huawei.com> |
2020-07-13 |
22 | Huaimo Chen | Uploaded new revision |
2020-07-12 |
21 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-21.txt |
2020-07-12 |
21 | (System) | New version approved |
2020-07-12 |
21 | (System) | Request for posting confirmation emailed to previous authors: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Qin WU <bill.wu@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com> |
2020-07-12 |
21 | Huaimo Chen | Uploaded new revision |
2020-07-12 |
20 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-12 |
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-12 |
20 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-20.txt |
2020-07-12 |
20 | (System) | New version approved |
2020-07-12 |
20 | (System) | Request for posting confirmation emailed to previous authors: Qin WU <bill.wu@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2020-07-12 |
20 | Huaimo Chen | Uploaded new revision |
2020-07-09 |
19 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-07-09 |
19 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-07-08 |
19 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-07-08 |
19 | Roman Danyliw | [Ballot comment] I concur with Alvaro Retana’s point (2) and (3), that since time synchronization is key to functionality clarified normative guidance is needed. I … [Ballot comment] I concur with Alvaro Retana’s point (2) and (3), that since time synchronization is key to functionality clarified normative guidance is needed. I support Ben Kaduk's DISCUSS position. ** Section 2.1. Thank you for providing a mapping of terms to references. ** Consider using normative language in the following places: -- Section 5.2.1. Per “The Start-Time indicates a time at or before which the schedule LSP must be set up”, should this be a normative MUST? -- Section 8. Per “Thus, such deployment should employ suitable PCEP security mechanisms …”, why not a normative SHOULD? ** Editorial Nits: -- Section 1. Typo. s/can not/cannot/ -- Section 5.2.1. Typo. s/an non zero/a non zero/g |
2020-07-08 |
19 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-07-08 |
19 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-07-08 |
19 | Robert Wilton | [Ballot comment] I found that document somewhat hard to read and support Alvaro's comment that this document would benefit from an editorial pass. However, it … [Ballot comment] I found that document somewhat hard to read and support Alvaro's comment that this document would benefit from an editorial pass. However, it is worth noting that I don't have much knowledge/experience of PCE. A few comments: Top level comment - should this draft be marked as "Experimental" if it unclear whether it will be implemented? 4.2.2.1. Elastic Time LSP Scheduling It wasn't quite clear to me how an end client would make use of elastic time scheduling. Is there some signalling mechanism to inform the client at the point in time that the tunnel has actually been set up, or otherwise how do they know when to make use of it? This might be worth clarifying in this section unless it is covered elsewhere. 4.2.2.2. Grace Periods I'm not really convinced that grace periods are worth it. I.e. the PCC client could trivially do the calculation and request the exact duration that they wanted which would slightly simplify the protocol messages. Is there any further justification as to why grace periods are requried? 5.2. LSP Object I'm not entirely convinced that it is that useful/necessary to have both messages. I would have probably just defined SCHED-PD-LSP-ATTRIBUTE TLV and treated the non repeating case as degenerate case (i.e. opt = "no-repeats", repeat-time-length = 0). 5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV It isn't clear to me whether a client can make a request for it to repeat forever (until cancelled), and if so, how that would be indicated. Did you consider other encodings of the "Opt" and "Repeat-time-length" fields: - I would have added "seconds", "minute", "hours" to the "Opt" field and removed "Options = 5: repeat every Repeat-time-length". - I would then always combine the "Opt" field with the "Repeat-time-length" field, e.g. so that you could express repeat every 12 hours as: (opt="hours", repeat-time-length=12), or every 30 minutes as (opt="minutes", repeat-time-length=30), etc. Hopefully these comment help to improve this document. Regards, Rob |
2020-07-08 |
19 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-07-08 |
19 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-07-07 |
19 | Benjamin Kaduk | [Ballot discuss] This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. … [Ballot discuss] This being a discuss ballot notwithstanding, the protocol mechanisms here seem pretty well thought-out; I'm just wanting changes to how they are described. There seems to be an internal inconsistency in Section 4.3, between "[t]he PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED" and "[t]he stateful PCE is required to update its local scheduled LSP-DB and scheduled TED". (I think the "SHOULD" one is wrong, personally.) Let's also take a closer look at the precise interdependency between the B bit and PD bit -- Section 5.1 implies that the PD bit itself cannot be set in the absence of the B bit, referring forward to Section 5.2.2, but Section 5.2.2 seems to only say that you need both the B and PD bits set in order to send SCHED-PD-LSP-ATTRIBUTE. Bits being set as a prerequisite for sending the TLV is a subtly different condition than having the one bit itself depend on the other, with correspondingly different error handling. Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is not defined in this document, rather, the reference should be to § 3.3 of RFC 8231. |
2020-07-07 |
19 | Benjamin Kaduk | [Ballot comment] I'm pretty sympathetic to Alvaro's not-quite-Discuss, but also am not quite prepared to elevate it to Discuss level (and incur the responsibility to … [Ballot comment] I'm pretty sympathetic to Alvaro's not-quite-Discuss, but also am not quite prepared to elevate it to Discuss level (and incur the responsibility to determine what changes are necessary to resolve it). I note several editorial comments and nits below, but those remarks are not comprehensive. Abstract so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. Just looking at this text in isolation, it's not entirely clear if the event that is scheduled is the LSP activation, creation, calculation, or something else, and whether it is just the computed path that depends on the resource usage/traffic duration, or if other things like the frequency of scheduling or the existence of an LSP at all would be dependent on those. Presumably the rest of the document will clarify, but perhaps there is some wordsmithing possible here. Section 1 letting other services use it when this service is not using it. The requirement of scheduled LSP provision is mentioned in [RFC8231] and nit(?): I think s/provision/provisioning/ [RFC7399]. A solution for providing more efficient network resource usage for traffic engineering is desired. Also, for deterministic nit: I don't really follow the connection between these two sentences -- "a solution for [...] is desired" seems to be a general re-statement of the problem, whereas the previous discussion has been discussing, essentially, the benefits of the proposed solution. Section 2.1 Hmm, RFC 8231 says that it itself takes the definitions for "Active Stateful PCE", "Passive Stateful PCE", and several other terms from RFC 8051; we should probably short-circuit the reference chain(s). Scheduled TED: Traffic engineering database with the awareness of scheduled resources for TE. This database is generated by the PCE from the information in TED and scheduled LSP-DB and allows knowing, at any time, the amount of available resources (does not include failures in the future). I'd consider "the expected amount of available resources (discounting the possibility of failures in the future)". Section 4.1 The LSP scheduling allows PCEs and PCCs to provide scheduled LSP for customers' traffic services at its actual usage time, so as to improve the network resource efficient utilization. nit: s/resource efficient utilization/resource utilization efficiency/ In case of implementing PCC-initiated scheduled LSPs, before a PCC delegates a scheduled LSP, it MAY use the PCReq/PCRep messages to Just to check: there is some risk that the computed path might change between this query and when the LSP actually becomes active? learn the path for the scheduled LSP. A PCC MUST delegate a scheduled LSP with information of its scheduling parameters, including the starting time and the duration using PCRpt message. I suggest "When delegating a scheduled LSP, a PCC MUST include its scheduling parameters, including [...]", to be clear about what cases the "MUST" applies to. (It might also be worth saying what a PCE should do if it receives a delegation request for a scheduled LSP that does not include the requisite parameters.) For a multiple PCE environment, a PCE MUST synchronize to other PCEs within the network, so as to keep their scheduling information synchronized. There are many ways that this could be achieved: one such mechanism is described in [I-D.litkowski-pce-state-sync]. Which way is used to achieve this is out of scope for this document. [...] I'd suggest restructuring how this paragraph is laid out (akin to Alvaro's comment). Specifically, it's an intrinsic fact that if you're in a multi-PCE environment, you have to have inter-PCE synchronization or the stat skew causes problems. That's not new with this document; what we are most interested in saying is that, in addition to the existing need to synchrnoize the TED and LSP-DB, when scheduled LSPs are in use you also have to synchronize the SLSP-DB and have each PCE reconstruct the Scheduled TED (or synchronize the Scheduled TED as well). The ways to perform such synchronization are hardly worth mentioning, except to the extent that existing mechanisms cannot handle sending the extra information. The scheduled LSP can also be initiated by PCE itself. In case of nit: missing article (perhaps "by a PCE itself"). scheduled LSP based on the local policy. For the former SCHED-LSP- ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message I suggest s/For the former/In the former case, the/ where as for the latter SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be nits: s/where as/whereas/, s/SCHED-LSP-ATTRIBUTE/the SCHED-LSP-ATTRIBUTE/ included. Either way the synchronization to other PCEs should be done when the scheduled LSP is created. I recognize that the BCP 14 keywords are not being used, but earlier we said "shall synchronize" but here it's just "synchronization should be done"; it's probably worth making these consistent. In both modes, for activation of scheduled LSPs, the PCC could initiate the setup of scheduled LSP at the start time by itself or wait for the PCE to update the PCC to initiate the setup of LSP. I'm worried about the "could initiate [...] or wait". While it's true that either party could take the initiative, doesn't there need to be an agreement between them about which one it will be, to avoid the risk of the LSP not actually geting instantiated at the start time? Similarly on the scheduling usage expires, the PCC could initiate the nit: s/expires/expiry/ or s/expires/expiration/ (Same comment about "could" as above.) Section 4.2.2 When an LSP is configured with a scheduling interval such as "[Ta, Tb] repeats 10 times with a repeat cycle a week" (representing 11 scheduling intervals), a path satisfying the constraints for the LSP in every interval represented by the periodical scheduling interval is computed once. And then the LSP along the path is set up to carry traffic in each of the scheduling intervals. If there is no path satisfying the constraints for some of the intervals, the LSP will not be set up at all. This seems to say that the same path must be used for each recurrence of the scheduled event, precluding some optimizations that might be desired in the face of other (unscheduled or differently scheduled) load. Is that intended? Section 4.2.2.1 When an LSP is configured with elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that the path satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv) and |Xv| is the minimum value for Xv from -P to Q. That is, [Ta+Xv, To check my understanding, this mention of |Xv| is indicating that the PCE attempts to limit the deviation from the requested interval, using an absolute value metric to indicate distance from the requested value? It might be worth putting in a few more words to indicate that this optimization is being performed; just "is the minimum value" could be confusing. Section 4.2.2.2 During grace periods from (Ta-GB) to Ta and from Tb to (Tb+GA), the LSP is up to carry traffic (maybe in best effort). This point seems pretty key to having grace periods at all. In particular, if there is no difference between the traffic-handling properties for the grace period and the "main interval", then the grace period is more simply handled by the entity requesting the interval (i.e., "just ask for a larger interval"). The fact that we propose to give different traffic-handling behavior during the grace period should be emphasized, in order to justify the existence of the protocol element. In the absence of such justifying text, I would propose to remove the grace-period feature as needless complexity. Section 4.3 For PCE-Initiated Scheduled LSP, the stateful PCE can compute a path for the scheduled LSP per requests from network management systems automatically based on the network resource availability in the scheduled TED, send a PCInitiate message with the path information nit: s/, send/ and send/ back to the PCC. Based on the local policy, the PCInitiate message could be sent immediately to ask PCC to create a scheduled LSP (as nit: s/ask PCC/ask the PCC/ o Based on the configuration (and the C flag in scheduled TLVs), when it is time (i.e., at the start time) for the LSP to be set up, either the PCC triggers the LSP to be signaled or the delegated PCE sends a PCUpd message to the head end LSR providing the updated path to be signaled (with A flag set to indicate LSP activation). We haven't discussed the C flag yet, so a reader is left wondering "how do I know whether the PCC or PCE is going to take initiative?". We could reword, perhaps like "When it is time for the LSP to be set up (i.e., at the start time), based on the value of the C flag for the scheduled TLV, either the PCC [...]". Similar changes would be applicable in later sections as well. Section 4.4 Are there any special considerations for modifying a periodic scheduled LSP after some recurrences have already happened? What about for modifying any scheduled LSP that is currently active (whether before the chage, after the change, or both)? Section 5.1 After a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase. For a multiple-PCE environment, the PCEs should also establish PCEP session and indicate its ability to support LSP scheduling among PCEP peers. The Open Object in the Open message Does a PCE need to refrain from advertising scheduling support to PCCs if its PCE peers do not all support scheduling? scheduling among PCEP peers. The Open Object in the Open message contains the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and updated in [RFC8281] and [RFC8232]". In this document, we define a new flag bit B (SCHED-LSP-CAPABLITY) flag for the STATEFUL-PCE- CAPABILITY TLV to indicate the support of LSP scheduling and another flag bit PD (PD-LSP-CAPABLITY) to indicate the support of LSP periodical scheduling. I note that (e.g.) RFC 8623 does not seem to give mnemonic names for the individual bits, so our "bit B" and "bit PD" seem a bit out of place. Section 5.2 Only one of these TLV SHOULD be present in the LSP object. In case more than one scheduling TLV is found, the first instance is processed and others ignored. It seems that this wording "more than one scheduling TLV" might apply to some hypothetical future TLV type for a different variation of scheduled LSPs. If that would be undesirable, we could reword to mention the two TLV types by name. Section 5.2.1 Please note that this formulation (number of seconds since a fixed time) is invariant to leap seconds, but that conversions from current UTC time to it might need to account for leap seconds. (Or if you want to ignore leap seconds, say that.) C (1 bit): Set to 1 to indicate the PCC is responsible to setup and remove the scheduled LSP based on the Start-Time and duration. I suggest noting that the PCE holds these responsibilities when the bit is set to zero. Start-Time (32 bits): This value in seconds, indicates when the scheduled LSP is used to carry traffic and the corresponding LSP must be setup and activated. Value of 0 MUST NOT be used in Start-Time. Note that the transmission delay SHOULD be considered when R=1 and the value of Start-Time is small. I don't understand why start-time of 0 is disallowed (for at least the R=0 case) -- that would disallow requesting a start time that happens to land on the time when the time counter wraps around, for no reason. The Start-Time indicates a time at or before which the scheduled LSP must be set up. The value of the Start-Time represents the number of seconds since the epoch when R bit is set to 0. When R bit is set to 1, it represents the number of seconds from the current time. In addition, it contains an non zero grace-before and grace-after if I suggest s/it/the SCHED-LSP-ATTRIBUTE TLV/; it's easy to misread the "it" as referring to the "Start-Time" from the previous paragraph. grace periods are configured. It includes an non zero elastic range Are the Grace-Before/Grace-After fields set to zero when grace periods are not configured? lower bound and upper bound if there is an elastic range configured. (Likewise for elastic-range.) Section 5.2.2 Opt: (4 bits) Indicates options to repeat. A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created. When a PCE receives a TLV with a Opt value not defined, it does not compute any path for the LSP. It generates a PCEP Error (PCErr) with a PCEP-ERROR object having Error-type = 4 (Not supported object) and Error- value = 4 (Unsupported parameter). Have we thought about what kind of negotiation might be needed in the case where a new Opt value is defined? Though the possibility currently seems unlikely, this error message does not seem sufficient to indicate which Opt value is problematic. NR: (12 bits) The number of repeats. In each of repeats, LSP carries traffic. Maybe say that NR==0 is equivalent to using SCHED-LSP-ATTRIBUTE (to avoid questions of 0- vs. 1-indexing)? Section 6.x We mention in several places "the scheduled TLVs" for the LSP object, but this seems misleading, since at most one scheduled TLV should be present in a given object. Perhaps "a scheduled TLV" would be better? Section 6.2 Perhaps it's worth noting that in the PCE-initiated case there is the option to avoid using the scheduled LSP TLVs (and, to some extent, PCUpd at all), since the PCE can just not tell the PCC about the scheduled path until its start-time occurs. Section 6.4 request the path computation based on scheduled TED and LSP-DB. A PCC MAY use PCReq message to obtain the scheduled path before delegating the LSP. [if my previous comment about "subject to change" results in text changes, similar changes would apply here] Section 6.5 Just to check: the scheduled TLV should still be included in the response even for a negative response? (Also, same comment about "obtain the scheduled path before delegating".) Section 8 Since we deal with scheduled events, we should remind implementations to do something reasonable when their current time jumps. Jumps can be forward or backward, and might cross boundaries for when LSPs should be (in)active. The presence of a significant time correction may be indicative of other (configuration) issues, and falling back to a conservative stance (keep LSPs active?) might be appropriate. Similarly, some discussion of how things break when there is clock skew between PCC and PCE might be useful (we already have a requirement for clock synchronization in discussion of the R flag). on the network. Thus, such deployment should employ suitable PCEP security mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [RFC8253]. The procedure based on Transport Layer Security (TLS) in [RFC8253] is considered a security enhancement and thus is much better suited for the sensitive information. PCCs may also need to nit: TCP-AO would be considered a "security enhancement" as well (compared to a baseline of unprotected TCP). Perhaps the intent is to say that the TLS procedure from RFC 8253 additionally provides confidentiality protection to the conveyed data? nit: "such deployments" plural. Section 9.1 When configuring the parameters about time, a user SHOULD consider leap-years and leap-seconds. I know I mentioned leap seconds earlier as well, but this feels like a cop-out. We can tell the reader in much more detail how leap years and seconds will affect their calculations, which in aggregate will be much more efficient than making each reader think it through for themself. Section 9.2 nit(?) "view the capability" (singular) sounds like it's just seeing whether the scheduled LSP functionality is enabled or not, a boolean value. If the intent is to say that the specific (e.g., per-tunnel) state should be visible, then this should be reworded accordingly. Section 9.4 Is there something to say about checking that LSPs are activated/disabled at the appropriate times for scheduled and periodic events? Section 9.5 Are there any requirements on PCE-to-PCE synchronization protocols that now need to carry the SLSP-DB? Section 10.1.1 Is there anything to say about why the two reserved values are reserved? |
2020-07-07 |
19 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-07-07 |
19 | Alvaro Retana | [Ballot comment] I think that this document still needs work before publication. I consider the first 3 points below to be close to DISCUSS-worthy. (1) … [Ballot comment] I think that this document still needs work before publication. I consider the first 3 points below to be close to DISCUSS-worthy. (1) In general, it feels like an editorial pass is needed to tighten up the language used as specification in this document. There are several places where the language feels loose -- as an example (from §4.4): In PCC-Initiated case, the PCC can send a PCRpt message for the scheduled LSP with updated parameters as well as scheduled information included in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) carried in the LSP Object. The PCE would take the updated resources and schedule into considerations and update the new path for the scheduled LSP to the PCC as well as synchronize to other PCEs in the network. In case path cannot be set based on new requirements, the previous LSP will not be impacted and the same should be conveyed by the use of empty ERO in the PCEP messages. "the PCC can send" Does it have to? If the information is not sent, then the PCE will not be able to calculate the path, so something stronger than "can" seems to be needed. "PCE would take" Does this mean that it is optional? I can imagine how the PCE may have local policies affecting the action...but I shouldn't have to imagine anything. "should be conveyed" Again, do you have to? Are there cases when it is ok not to do it? Not everything needs rfc2119 key words, but in some cases they would help. In this case, I can see a couple of variations possible. rfc2119> ...the PCC MUST send...the PCE SHOULD take...MUST be conveyed... non-rfc2119> ...the PCC sends...the PCE takes...is conveyed... (2) §4.1: "a PCE MUST synchronize to other PCEs within the network...Which way is used to achieve this is out of scope for this document." If the synchronization mechanism is out of scope, how can an implementation be compliant with this specification? IOW, if there's nothing to normatively refer to, then normative language shouldn't be used, or a mechanism should be mandated. In either case, because synchronization between the PCEs seems important for this specification, I would like to also see a discussion about the specific effects on LSP scheduling instead of the generic pointer to rfc7399. §4.3 says that the "stateful PCE...shall send a PCRpt message with the scheduled LSP to other PCEs...to achieve...synchronization." Even though normative language is not used, the intent seems to specifically point at using PCRpt messages for synchronization... Besides the confusing use of language, rfc8231 defines PCRpt as a "message sent by a PCC to a PCE to report the current state of an LSP", but I didn't see where the use if defined between PCEs -- maybe I missed it. §6.1 does reinforce that the "Path Computation State Report (PCRpt) is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs as per [RFC8231]....This message is also used to synchronize the scheduled LSPs to other PCE as described in [RFC8231]". But this last point is what I can't find in rfc8231. (3) This whole document is about scheduling LSPs, which would seem to require time synchronization. However, I found only one mention: "It is necessary to synchronize the clocks of the PCEs and PCCs when relative time is used." Should this sentence use normative language? Is there a recommended way to achieve time synchronization? This seems to be an important manageability consideration that impacts network operations. (4) rfc8413 should be a Normative reference because it "provides a framework that describes and discusses the problem, and defines an appropriate architecture for the scheduled reservation of TE resources", which is the basis for the extensions defined in this document. (5) §2.1: Some of the terminology terms have 2 references -- that caught my attention. For example, the definition of TED points at both rfc5440 and rfc8231. rfc5440 has a definition, but rfc8231 points at rfc4655. Luckily, the definitions in rfc5440 and rfc4655 are the same...but the added indirection through rfc8231 is unnecessary. Please revalidate the references and include only one. (6) §2.1: "Duration: This value indicates the time duration..." Please don't use "duration" to define "duration". Maybe s/time duration/length of time (7) §4.1: "A PCC MUST delegate a scheduled LSP with information of its scheduling parameters, including the starting time and the duration using PCRpt message." This sentence seems to refer to the use of the new TLVs defined later in the test. Please include a forward reference to make it easier for the reader to figure out how this action would be done. (8) §4.3: "The PCE SHOULD add the scheduled LSP into its scheduled LSP-DB and update its scheduled TED." When is it ok for the PCE not to add this information? IOW, why is MUST not used? If the information is not added, what is the effect on the required synchronization? Later in this section: "The stateful PCE is required to update its local scheduled LSP-DB and scheduled TED with the scheduled LSP." Even though normative language is not used here, the intent of requiring an update to the databases seems different than above and results in confusion. (9) §4.3: "the PCC knows that it is a scheduled path" How? I'm sure that it is through the contents of the messages. Please be specific. (10) §5.1: "After a PCEP session has been established, a PCC and a PCE indicates its ability to support LSP scheduling during the PCEP session establishment phase." Is it after or during? (11) §5.1: "...the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231]. Note that the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]..." Redundant. (12) §5.1: "we define a new flag bit B (SCHED-LSP-CAPABLITY) flag...B (LSP-SCHEDULING-CAPABILITY..." The names don't match. (13) §5.1: "Setting PD bit requires setting B bit as specified in 5.2.2." That is not specified in §5.2.2. However, it brings up the question about the interpretation of only receiving the PD bit set -- I'm assuming that it should be ignored unless the B but is also set, right? If so, please specify it! (14) §5.2: "this LSP is requesting scheduled parameters" The request is by the PCC, not the LSP... (15) §5.2: "scheduled LSP attribute TLV" Even though it may be obvious, the SCHED-LSP-ATTRIBUTE TLV is not called "scheduled LSP attribute TLV" anywhere in the document. (16) §5.2: "For periodical LSPs, the SCHED-PD-LSP-ATTRIBUTE TLV can be used in LSP Object for each periodic scheduled LSP carried in the PCEP messages." Don't you *have* to use it? Otherwise, how would the periodic nature be known? (17) §5.2: "Only one of these TLV SHOULD be present in the LSP object. In case more than one scheduling TLV is found, the first instance is processed and others ignored." This section talks about both the SCHED-LSP-ATTRIBUTE and the SCHED-PD-LSP-ATTRIBUTE TLVs -- the sentence sounds as if only one of them (either one) should be present. Please rephrase -- it may be better to define this behavior for each TLV independently (in §5.2.*). (18) §5.2.1: "This TLV MUST NOT be included unless both PCEP peers have set the B..." What should the receiver do if the TLV is received when both peers didn't set the B bit? (19) §5.2.1: "Just before the wraparound, if the time at which the LSP is to be activated is after the wraparound..." I don't know how that is possible. (20) §5.2.1: "...non-zero grace period or elastic range, but it MUST NOT provide both for an LSP." What should a receiver do if both sets are non-zero? (21) §5.2.2: "This TLV MUST NOT be included unless both PCEP peers have set the B...and PD..." What should the receiver do if the TLV is received but both bits were not set? (22) §5.2.2: "A new registry "Opt" under SCHED-PD-LSP-ATTRIBUTE is created." The registry is not part of the definition of the field...this sentence is not needed here. (23) §5.2.2: "Opt value not defined" I think you may mean an unknown value (or maybe unsupported). (24) Nits: s/following terminologies are re-used/following terminology is re-used s/computes a path/compute a path/g s/by PCE itself/by a|the PCE itself s/setup of LSP/setup of an LSP s/ask PCC/ask the PCC s/In PCC-Initiated case/In the PCC-Initiated case/g s/In PCE-Initiated case/In the PCE-Initiated case/g s/establish PCEP session/establish a PCEP session s/Setting PD bit requires setting B bit/Setting the PD bit requires setting the B bit s/presence of SCHED-LSP-ATTRIBUTE/presence of the SCHED-LSP-ATTRIBUTE s/in LSP Object/in the LSP Object/g s/one of these TLV/one of these TLVs s/B (LSP-SCHEDULING-CAPABILITY bit)/B (LSP-SCHEDULING-CAPABILITY) bit/g s/Following flags/The following flags s/remains same as/remain the same as in the s/Options =/Opt = s/In each of repeats, /During each repetition §6.1: s/described in [RFC8231]/described in [RFC8231]. |
2020-07-07 |
19 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-07-06 |
19 | Murray Kucherawy | [Ballot comment] Section 2.1: * "Passive Stateful PCE" is listed in the imported terminology, but not used elsewhere in the document. Sections 5.2.1 & 5.2.2: … [Ballot comment] Section 2.1: * "Passive Stateful PCE" is listed in the imported terminology, but not used elsewhere in the document. Sections 5.2.1 & 5.2.2: * I had the same questions Erik did about the R-bit. Section 7: The text here is unchanged since version -09 of this document, which recorded no known implementations, and was posted almost a year ago. Is that still the case now? Section 10.1.1: This section defines a new registry but doesn't explicitly describe the fields of that registry like Section 10.1.2 does. It's nice to be explicit about these things, in my opinion. |
2020-07-06 |
19 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-07-06 |
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-06 |
19 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-19.txt |
2020-07-06 |
19 | (System) | New version approved |
2020-07-06 |
19 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Qin WU <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Zhuangyan <zhuangyan.zhuang@huawei.com> |
2020-07-06 |
19 | Huaimo Chen | Uploaded new revision |
2020-07-06 |
18 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below one non-blocking COMMENTs. I hope that this helps to improve the … [Ballot comment] Thank you for the work put into this document. Please find below one non-blocking COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4.2.2.1 -- May be am I failing to understand this part of the sentence "|X| is the minimum value from 0 to max(P, Q)" as it is not the same as "where -P <= X <= Q" or does the "|X|" not represent the absolute value of X ? == NITS == -- Section 4.2.2.1 -- Please use "are" rather than "is" in "Note that both Ta and Tb is shifted by the same 'X'" |
2020-07-06 |
18 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-07-05 |
18 | Erik Kline | [Ballot comment] [ section 1 ] * "the service really being used" -> "the service is really being used"? [ section 4.1 ] * "SHALL … [Ballot comment] [ section 1 ] * "the service really being used" -> "the service is really being used"? [ section 4.1 ] * "SHALL check ... and computes" -> "... and compute" * "on the scheduling usage expires" -> "on scheduled usage expiration"? [ section 4.2.2 ] * If there is no possible path do you want some text, maybe even just a lowercase should, about "should report to an administrator" or something? [ section 4.3 ] * In the first of the 4 bullet points at the end of this section, should the "required" and "shall" be capitalized? [ section 4.5 ] * "In other case," -> "In all other cases," or just "Otherwise,"? [ section 5.1 ] * Perhaps there's a way to strengthen the "PD requires B" text by saying what an endpoint should do if it sees PD without B? [ section 5.2.1 & 5.2.2 ] * R bit. WRT to R=0 and the wraparound, it would seem to me that in this case the receiver really needs to check if start-time is less than the current time, and if so treat that as wrap-around (2106) + start-time number of seconds. Otherwise, I think you'll need to be more precise about what it means to be "near" the wrap-around. Even still, if times are not sync'd carefully and the start-time is not a moderate amount of time in the future there remains a chance that an endpoint could receive a start-time it perceives as "in the past". What should an endpoint in this circumstance? Yet another alternative is to take a flag bit to indicate that start-time is after the wrap-around, and say that by 2242 CE some other solution should be found. :-) * Duration: Is a value of 1 just as nonsensical as 0? What about a value of 0 if grace-before and grace-after are non-zero? I may not understand the grace and elastic uses properly, but it seems to me that the thing to forbid is an "effective duration" of 0 (i.e. factoring in grace or elastic values). * Grace and Elastic fields: If it cannot provide both simultaneously why have both fields? What just have a "lower" and "upper" pair of fields and choose a new flag value to indicate whether the fields are grace values or elastic values? |
2020-07-05 |
18 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-06-30 |
18 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-28 |
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-06-28 |
18 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-18.txt |
2020-06-28 |
18 | (System) | New version approved |
2020-06-28 |
18 | (System) | Request for posting confirmation emailed to previous authors: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Qin WU <bill.wu@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com> |
2020-06-28 |
18 | Huaimo Chen | Uploaded new revision |
2020-06-22 |
17 | Cindy Morgan | Placed on agenda for telechat - 2020-07-09 |
2020-06-22 |
17 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-06-22 |
17 | Deborah Brungard | Ballot has been issued |
2020-06-22 |
17 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2020-06-22 |
17 | Deborah Brungard | Created "Approve" ballot |
2020-06-22 |
17 | Deborah Brungard | Ballot writeup was changed |
2020-06-17 |
17 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-16 |
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-06-16 |
17 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-17.txt |
2020-06-16 |
17 | (System) | New version approved |
2020-06-16 |
17 | (System) | Request for posting confirmation emailed to previous authors: Zhuangyan <zhuangyan.zhuang@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com> |
2020-06-16 |
17 | Huaimo Chen | Uploaded new revision |
2020-06-12 |
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-06-12 |
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-pce-lsp-scheduling-16. If any part of this review is inaccurate, please let us … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-pce-lsp-scheduling-16. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ two, new registrations are to be made as follows: Value: [ TBD-at-Registration ] Description: SCHED-LSP-ATTRIBUTE Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: SCHED-PD-LSP-ATTRIBUTE Reference: [ RFC-to-be ] Second, a new registry is to be created called the Opt registry. IANA Question --> Could this registry be given a more descriptive name that distinguishes it from other "option" registries? IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry is managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: Value Name Reference ----- ---- ---------- 0 Reserved 1 REPEAT-EVERY-DAY [ RFC-to-be ] 2 REPEAT-EVERY-WEEK [ RFC-to-be ] 3 REPEAT-EVERY-MONTH [ RFC-to-be ] 4 REPEAT-EVERY-YEAR [ RFC-to-be ] 5 REPEAT-EVERY-REPEAT-TIME-LENGTH [ RFC-to-be ] 6-14 Unassigned 15 Reserved Third, a new registry is to be created called the Schedule TLVs Flag Field registry. It is to be a new registry on the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ The new registry will be managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: Bit Description Reference 0-4 Unassigned 5 R-bit [ RFC-to-be ] 6 C-bit [ RFC-to-be ] 7 A-bit [ RFC-to-be ] Fourth, in the STATEFUL-PCE-CAPABILITY TLV Flag Field also on the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ two, new registrations are to be made as follows: Value: [ TBD-at-Registration ] Description: LSP-SCHEDULING-CAPABILITY (B-bit) Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Description: PD-LSP-CAPABLITY (PD-bit) Reference: [ RFC-to-be ] Fifth, in the PCEP-ERROR Object Error Types and Values registry also on the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at: https://www.iana.org/assignments/pcep/ two, new error values will be registered as follows: Error-Type Meaning 6 Mandatory Object missing Error-value [ TBD-at-Registration ]: Scheduled TLV missing [ RFC-to-be ] 19 Invalid Operation Error-value [ RFC-to-be ]: Attempted LSP Scheduling if the scheduling capability was not advertised [ RFC-to-be ] The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-06-12 |
16 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-16.txt |
2020-06-12 |
16 | (System) | New version approved |
2020-06-12 |
16 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com> |
2020-06-12 |
16 | Huaimo Chen | Uploaded new revision |
2020-06-12 |
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-06-11 |
15 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-15.txt |
2020-06-11 |
15 | (System) | New version approved |
2020-06-11 |
15 | (System) | Request for posting confirmation emailed to previous authors: Qin WU <bill.wu@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2020-06-11 |
15 | Huaimo Chen | Uploaded new revision |
2020-06-10 |
14 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-14.txt |
2020-06-10 |
14 | (System) | New version approved |
2020-06-10 |
14 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com> |
2020-06-10 |
14 | Huaimo Chen | Uploaded new revision |
2020-06-09 |
13 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. Sent review to list. |
2020-06-05 |
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2020-06-05 |
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2020-06-04 |
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2020-06-04 |
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Gillmor |
2020-06-03 |
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2020-06-03 |
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2020-05-29 |
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-05-29 |
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-06-12): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: adrian@olddog.co.uk, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, … The following Last Call announcement was sent out (ends 2020-06-12): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: adrian@olddog.co.uk, pce-chairs@ietf.org, pce@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, draft-ietf-pce-stateful-pce-lsp-scheduling@ietf.org, db3546@att.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-pce-stateful-pce-lsp-scheduling-13.txt> (PCEP Extensions for LSP scheduling with 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 LSP scheduling with stateful PCE' <draft-ietf-pce-stateful-pce-lsp-scheduling-13.txt> 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 last-call@ietf.org mailing lists by 2020-06-12. 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 This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-lsp-scheduling/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3682/ https://datatracker.ietf.org/ipr/3683/ https://datatracker.ietf.org/ipr/3044/ |
2020-05-29 |
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-05-29 |
13 | Deborah Brungard | Last call was requested |
2020-05-29 |
13 | Deborah Brungard | Ballot approval text was generated |
2020-05-29 |
13 | Deborah Brungard | Ballot writeup was generated |
2020-05-29 |
13 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2020-05-29 |
13 | Deborah Brungard | Last call announcement was changed |
2020-03-23 |
13 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-13.txt |
2020-03-23 |
13 | (System) | New version approved |
2020-03-23 |
13 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com> |
2020-03-23 |
13 | Huaimo Chen | Uploaded new revision |
2020-03-22 |
12 | Carlos Pignataro | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2020-03-05 |
12 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2020-03-05 |
12 | Min Ye | Request for Early review by RTGDIR is assigned to Carlos Pignataro |
2020-03-05 |
12 | Dhruv Dhody | Shepherd write-up for draft-ietf-pce-stateful-pce-lsp-scheduling-12 Document shepherd: Adrian Farrel <adrian@olddog.co.uk> (1) What type of RFC is being requested Publication is requested as a Proposed Standard. This … Shepherd write-up for draft-ietf-pce-stateful-pce-lsp-scheduling-12 Document shepherd: Adrian Farrel <adrian@olddog.co.uk> (1) What type of RFC is being requested Publication is requested as a Proposed Standard. This document includes the specification of protocol elements and extensions to an existing standards track protocol. This makes Proposed Standard appropriate. The RFC type is indicated in the document header. (2) Please provide such a Document Announcement Write-Up. Technical Summary: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. Working Group Summary: The working group process took 2.5 years and 12 revisions. This was based on the previous 2 years and 5 revisions as an individual I-D. The process has not contained anything noteworthy. Document Quality: This document contains an implementation status section per RFC 7942 and according to PCE WG policy. The section indicates suggested plans for implementation by two vendors. The document shepherd is aware of additional plans to implement in a private research implementation of PCEP. The document has not received any expert reviews. Personnel: Document shepherd: Adrian Farrel <adrian@olddog.co.uk> Responsible Area Director: Deborah Brungard <db3546@att.com> (3) Briefly describe the review of this document that was performed by the Document Shepherd. I have reviewed this document several times as a WG particpant, when I was WG co-chair, and during WG last call. It was of particular interest to me as co-editor of RFC 8413. I also did a shepherd review after WG last call leading to a few fixes, and an additional issue raised while composing this write-up led to another revision. The authors have addressed all of my comments, and I consider the document ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I would, of course, have preferred to see a review from an implementer, but as the author team and large contributor team include many people familiar with PCEP and several of those who would be called upon to implement, I think any concern is mitigated. (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. In addition to the declaration in the boilerplate of the document, each author and contributor has made an explicit declaration at https://mailarchive.ietf.org/arch/msg/pce/MW9cjP8T5DC1gNkQgsRfaJ14O5U (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The datatrcker shows three IPR disclosures. https://datatracker.ietf.org/ipr/3044/ https://datatracker.ietf.org/ipr/3682/ https://datatracker.ietf.org/ipr/3683/ The first of these was disclosed early in the process. The other two were disclosed just before working group last call. All were announced on the working group mailing list and attracted no comments. (9) How solid is the WG consensus behind this document? The consensus is reasonable. It is a moderately small working group with a total of 12 people involved in the document as authors or contributors meaning that the number of additional reviewers available was not large. Nevertheless, the working group last call attracted the following comments from non-contributor/authors: - I have read it and support it - I'm an operator and consider this gives an operator flexiblity - Support - I have read this draft and consider it ready for publication - I support publication - Support publication - Support publication - I read the draft and strongly support its publication. I see such requirement in real networks too There were no negative comments or requests for further edits. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? None. (11) Identify any ID nits the Document Shepherd has found in this document. idnits is clean except for the general progress of references that can be cleaned up later. (12) Describe how the document meets any required formal review criteria. No formal review is applicable. (13) Have all references within this document been identified as either normative or informative? Yes, see sections 12.1 and 12.2 (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No. (15) Are there downward normative references references (see RFC 3967)? No downrefs in this document. (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, especially with regard to its consistency with the body of the document. I have read and re-read the IANA section and cross-checked it against the existing registries, RFC 8126, and the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirmed. Confirm that any referenced IANA registries have been clearly identified. Confirmed 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 8126). Confirmed. (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, such as XML code, BNF rules, MIB definitions, YANG modules, etc. None appropriate. (20) If the document contains a YANG module. No YANG |
2020-03-05 |
12 | Dhruv Dhody | Responsible AD changed to Deborah Brungard |
2020-03-05 |
12 | Dhruv Dhody | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-03-05 |
12 | Dhruv Dhody | IESG state changed to Publication Requested from I-D Exists |
2020-03-05 |
12 | Dhruv Dhody | IESG process started in state Publication Requested |
2020-03-05 |
12 | Dhruv Dhody | Tag Doc Shepherd Follow-up Underway cleared. |
2020-03-05 |
12 | Dhruv Dhody | Changed consensus to Yes from Unknown |
2020-03-05 |
12 | Dhruv Dhody | Intended Status changed to Proposed Standard from None |
2020-03-04 |
12 | Adrian Farrel | Shepherd write-up for draft-ietf-pce-stateful-pce-lsp-scheduling-12 Document shepherd: Adrian Farrel <adrian@olddog.co.uk> (1) What type of RFC is being requested Publication is requested as a Proposed Standard. This … Shepherd write-up for draft-ietf-pce-stateful-pce-lsp-scheduling-12 Document shepherd: Adrian Farrel <adrian@olddog.co.uk> (1) What type of RFC is being requested Publication is requested as a Proposed Standard. This document includes the specification of protocol elements and extensions to an existing standards track protocol. This makes Proposed Standard appropriate. The RFC type is indicated in the document header. (2) Please provide such a Document Announcement Write-Up. Technical Summary: This document defines a set of extensions needed to the stateful Path Computation Element (PCE) communication Protocol (PCEP), so as to enable Labeled Switched Path (LSP) scheduling for path computation and LSP setup/deletion based on the actual network resource usage and the duration of a traffic service in a centralized network environment as stated in RFC 8413. Working Group Summary: The working group process took 2.5 years and 12 revisions. This was based on the previous 2 years and 5 revisions as an individual I-D. The process has not contained anything noteworthy. Document Quality: This document contains an implementation status section per RFC 7942 and according to PCE WG policy. The section indicates suggested plans for implementation by two vendors. The document shepherd is aware of additional plans to implement in a private research implementation of PCEP. The document has not received any expert reviews. Personnel: Document shepherd: Adrian Farrel <adrian@olddog.co.uk> Responsible Area Director: Deborah Brungard <db3546@att.com> (3) Briefly describe the review of this document that was performed by the Document Shepherd. I have reviewed this document several times as a WG particpant, when I was WG co-chair, and during WG last call. It was of particular interest to me as co-editor of RFC 8413. I also did a shepherd review after WG last call leading to a few fixes, and an additional issue raised while composing this write-up led to another revision. The authors have addressed all of my comments, and I consider the document ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I would, of course, have preferred to see a review from an implementer, but as the author team and large contributor team include many people familiar with PCEP and several of those who would be called upon to implement, I think any concern is mitigated. (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. In addition to the declaration in the boilerplate of the document, each author and contributor has made an explicit declaration at https://mailarchive.ietf.org/arch/msg/pce/MW9cjP8T5DC1gNkQgsRfaJ14O5U (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The datatrcker shows three IPR disclosures. https://datatracker.ietf.org/ipr/3044/ https://datatracker.ietf.org/ipr/3682/ https://datatracker.ietf.org/ipr/3683/ The first of these was disclosed early in the process. The other two were disclosed just before working group last call. All were announced on the working group mailing list and attracted no comments. (9) How solid is the WG consensus behind this document? The consensus is reasonable. It is a moderately small working group with a total of 12 people involved in the document as authors or contributors meaning that the number of additional reviewers available was not large. Nevertheless, the working group last call attracted the following comments from non-contributor/authors: - I have read it and support it - I'm an operator and consider this gives an operator flexiblity - Support - I have read this draft and consider it ready for publication - I support publication - Support publication - Support publication - I read the draft and strongly support its publication. I see such requirement in real networks too There were no negative comments or requests for further edits. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? None. (11) Identify any ID nits the Document Shepherd has found in this document. idnits is clean except for the general progress of references that can be cleaned up later. (12) Describe how the document meets any required formal review criteria. No formal review is applicable. (13) Have all references within this document been identified as either normative or informative? Yes, see sections 12.1 and 12.2 (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No. (15) Are there downward normative references references (see RFC 3967)? No downrefs in this document. (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, especially with regard to its consistency with the body of the document. I have read and re-read the IANA section and cross-checked it against the existing registries, RFC 8126, and the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirmed. Confirm that any referenced IANA registries have been clearly identified. Confirmed 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 8126). Confirmed. (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, such as XML code, BNF rules, MIB definitions, YANG modules, etc. None appropriate. (20) If the document contains a YANG module. No YANG |
2020-03-04 |
12 | Dhruv Dhody | Requested Early review by RTGDIR |
2020-01-17 |
12 | Julien Meuric | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2020-01-16 |
12 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-12.txt |
2020-01-16 |
12 | (System) | New version approved |
2020-01-16 |
12 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com> |
2020-01-16 |
12 | Huaimo Chen | Uploaded new revision |
2020-01-14 |
11 | Julien Meuric | Tag Doc Shepherd Follow-up Underway set. |
2020-01-14 |
11 | Julien Meuric | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2020-01-05 |
11 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-11.txt |
2020-01-05 |
11 | (System) | New version approved |
2020-01-05 |
11 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com> |
2020-01-05 |
11 | Huaimo Chen | Uploaded new revision |
2019-12-19 |
10 | Julien Meuric | IPR poll: https://mailarchive.ietf.org/arch/msg/pce/MW9cjP8T5DC1gNkQgsRfaJ14O5U |
2019-12-11 |
10 | Dhruv Dhody | Notification list changed to Adrian Farrel <adrian@olddog.co.uk> |
2019-12-11 |
10 | Dhruv Dhody | Document shepherd changed to Adrian Farrel |
2019-12-05 |
10 | Dhruv Dhody | IETF WG state changed to In WG Last Call from WG Document |
2019-10-23 |
10 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-10.txt |
2019-10-23 |
10 | (System) | New version approved |
2019-10-23 |
10 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin WU <bill.wu@huawei.com> |
2019-10-23 |
10 | Huaimo Chen | Uploaded new revision |
2019-08-16 |
09 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-09.txt |
2019-08-16 |
09 | (System) | New version approved |
2019-08-16 |
09 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@futurewei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin Wu <bill.wu@huawei.com> |
2019-08-16 |
09 | Huaimo Chen | Uploaded new revision |
2019-08-14 |
Jenny Bui | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-stateful-pce-lsp-scheduling | |
2019-08-14 |
Jenny Bui | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-stateful-pce-lsp-scheduling | |
2019-07-07 |
08 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-08.txt |
2019-07-07 |
08 | (System) | New version approved |
2019-07-07 |
08 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Qin Wu <bill.wu@huawei.com>, pce-chairs@ietf.org |
2019-07-07 |
08 | Huaimo Chen | Uploaded new revision |
2019-02-16 |
07 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-07.txt |
2019-02-16 |
07 | (System) | New version approved |
2019-02-16 |
07 | (System) | Request for posting confirmation emailed to previous authors: Zhuangyan <zhuangyan.zhuang@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, pce-chairs@ietf.org, Huaimo Chen <huaimo.chen@huawei.com>, Qin Wu <bill.wu@huawei.com> |
2019-02-16 |
07 | Huaimo Chen | Uploaded new revision |
2019-02-16 |
06 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-06.txt |
2019-02-16 |
06 | (System) | New version approved |
2019-02-16 |
06 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2019-02-16 |
06 | Huaimo Chen | Uploaded new revision |
2018-12-22 |
05 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-05.txt |
2018-12-22 |
05 | (System) | New version approved |
2018-12-22 |
05 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2018-12-22 |
05 | Huaimo Chen | Uploaded new revision |
2018-12-19 |
04 | Dhruv Dhody | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-04.txt |
2018-12-19 |
04 | (System) | New version approved |
2018-12-19 |
04 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2018-12-19 |
04 | Dhruv Dhody | Uploaded new revision |
2018-06-18 |
03 | Dhruv Dhody | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-03.txt |
2018-06-18 |
03 | (System) | New version approved |
2018-06-18 |
03 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2018-06-18 |
03 | Dhruv Dhody | Uploaded new revision |
2018-03-02 |
02 | Dhruv Dhody | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-02.txt |
2018-03-02 |
02 | (System) | New version approved |
2018-03-02 |
02 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2018-03-02 |
02 | Dhruv Dhody | Uploaded new revision |
2018-03-02 |
01 | Dhruv Dhody | on WG adoption |
2018-03-02 |
01 | Dhruv Dhody | This document now replaces draft-zhuang-pce-stateful-pce-lsp-scheduling instead of None |
2017-10-15 |
01 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-01.txt |
2017-10-15 |
01 | (System) | New version approved |
2017-10-15 |
01 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen <huaimo.chen@huawei.com>, Zhuangyan <zhuangyan.zhuang@huawei.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, Qin Wu <bill.wu@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> |
2017-10-15 |
01 | Huaimo Chen | Uploaded new revision |
2017-08-02 |
Jasmine Magallanes | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-stateful-pce-lsp-scheduling | |
2017-06-30 |
00 | Huaimo Chen | New version available: draft-ietf-pce-stateful-pce-lsp-scheduling-00.txt |
2017-06-30 |
00 | (System) | WG -00 approved |
2017-06-30 |
00 | Huaimo Chen | Set submitter to "Huaimo Chen <huaimo.chen@huawei.com>", replaces to (none) and sent approval email to group chairs: pce-chairs@ietf.org |
2017-06-30 |
00 | Huaimo Chen | Uploaded new revision |