1 / 49

Flowchart and Timing

Flowchart and Timing. 03/11/14 Recommendation. GOALS. Finish going through the process flowchart listing the steps and various options for each.

irish
Download Presentation

Flowchart and Timing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Flowchart and Timing 03/11/14 Recommendation

  2. GOALS • Finish going through the process flowchart listing the steps and various options for each. • Develop options (choices) for each step, such as defender priority, ability to meet/exceed, match by changing start and/or stop date, etc. and give recommendation to each. • Develop a proposal on the sandbox (or something like the presubmittal workspace) and develop the recommendation. This needs to be settled because a lot of issues/decisions will vary depending upon what we do here.

  3. OPTIONS BEING DISCUSSED • Options Being Discussed • Initial evaluation • Provider evaluation time limit • Queue protection • Matching evaluation timing • Matching evaluations • Challenger confirmation time limit • Challenger REBID • Binding the defender vs. Do no harm • Opt out flags • “Issues and Requirements for ROFR Defender Assignment” worksheet

  4. Initial evaluation • The TP cannot continuously reevaluate a challenger based on changing conditions. The process must be initiated based on a given or initial evaluation. • In order to ensure the TP has time to evaluate and initiate the P&C process a measure must be put into place to allow the TP to select an evaluation and disregard subsequent updates. • Even in fully automated systems there is a delay between initiating an evaluation and initiating the P&C process. Changes to the defender set must be taken into account

  5. Initial evaluationA-Defenders • If A-Defenders change status during an evaluation then the challenger must be reevaluated. • Option 1: Suspend customer action on identified A- defenders • Set the competing flag upon identification as an A-defender. This will suspend customer initiated actions. • Offers the greatest simplicity and transparency • Can be applied consistently across ROFR and non-ROFR scenarios

  6. Initial evaluationA-Defenders (cont.) • Option 2: Allow SUPERSEDED to be performed from the CONFIRMED state. Applies only when an A-defender confirms after P&C has been initiated. • Requires a change to the state transition diagram • Introduces some complexity to the process • No deviation from normal TSR processing from the customer standpoint • Could be seen as not honoring ROFR if an A-defender confirms and would normally have ROFR

  7. Initial evaluationA-Defenders (cont.) • Option 3: If the SUPERSEDED action is unsuccessful on any A-Defenders due to confirmation then reevaluate the challenger. • Requires a flowchart change to put SUPERSEDED before accepting the challenger. • Open to the ‘clear the queue’ game • Some embedded processing delay • No deviation from normal TSR processing from the customer standpoint

  8. Initial evaluationFlowchart recommendation • TP begins the evaluation process for a TSR that has been identified as a challenger. • TP captures the information required for evaluation. Subsequent system condition changes will not be required to be considered. • TP performs the evaluation of the challenger and sets the competing flag on the challenger and all defenders. • Prior to initiating P&C TP performs a final review to ensure all defenders remain valid and of the same type. If not then reevaluate the challenger. (Motion 84)

  9. Initial evaluation Motion 2 • Motion 2: “Once the list of Defenders needed to provide full service to the challenger has been established, The TP shall not be required to perform any further evaluations of the challenger based on system conditions.”

  10. Initial evaluation Motion 3 • Motion 3: “When a TSR is identified as an A-Defender the COMPETING_REQUEST_FLAG shall be set to ‘Y’. Customer initiated status changes shall not be permitted from a pending status when the COMPETING_REQUEST_FLAG is set. Once the preemption and /or competition has concluded the COMPETING_REQUEST_FLAG shall be set to ‘N’. Customer initiated status changes shall be permitted at this point. Once the COMPETING_REQUEST_FLAG is set for all A-Defenders the Transmission Provider may perform a final review prior to initiating Preemption and Competition to ensure all defenders remain valid and of the same type. If all defenders are not valid and of the same type the Transmission Provider may perform a full reevaluation of the challenger.”

  11. Provider evaluation time limit • Once a competition has been initiated subsequently queued TSRs that impact the same time points and elements must wait for the pending competition to complete prior to being processed. • This will force TPs to violate the Provider Evaluation Time Limit as defined in Table 4-2. • Example: • Two Non-Firm Weekly TSRs are queued for the same path and time frame. • The first TSR is identified as a challenger with weekly ROFR defenders. Defenders have 24 hours to match. • TP has 4 hours to evaluate the second TSR.

  12. Provider evaluation time limitrecommendation • Option 1: Do not start the clock on the Provider Evaluation Time Limit until all pending competitions are complete • Requires modification to Table 4-2 footnote 1 • Option 2: Reduce Matching time limits as needed • Required reductions would be too severe

  13. Provider evaluation time limitMotion 4 • Motion 4 “If evaluation of a TSR is contingent on a pending competition(s), Provider Evaluation Time Limit as defined in Table 4-2 shall not start until all pending competitions have completed.”

  14. Queue protection • Shorter term TSRs may be queued behind longer term TSRs based on the TP’s timing rules. • If the longer term TSR enters into P&C this may cause undue delay in processing the shorter term TSR. • Example: • A Non-Firm Weekly TSR is queued Monday at 16:00 with a start time of 00:00 Wednesday. • NF Weekly enters into P&C. Defender has 24 hour Matching time limit. TP has 4 hour evaluation time. • NF hourly TSRs queued Tuesday for Wednesday service will not receive a response until after 20:00 Tuesday evening.

  15. Queue protection recommendation • A general provision is needed that gives TPs the flexibility to account for this circumstance. • The provision must be limited enough to prevent abuse but be broad enough to provide protections. • The provision should apply to each challenger. There should not be a variance for each possible scenario. • The provision is best implemented using the concept of challenger lead time. • Challenger lead time is the time in advance of start of service a TSR must be QUEUED in order to qualify as a challenger. (Motion 79)

  16. Queue protection motion 5 • Motion 5: • “The TP may extend a Non-Firm challenger’s competition lead time to prevent the Preemption and Competition process from introducing undue delays in the timely processing of shorter term requests. This only applies when: • A shorter term request could be queued after a longer term challenger • The longer term challenger could have ROFR defenders • The shorter term request could not otherwise be processed until the longer term challenger’s competition is completed”

  17. Matching evaluation Timing • The TP requires time to evaluate MATCHING requests as they are received. • Given that a defender may submit a Match at the last moment, this time cannot be embedded in the MATCHING Response Time Limit • An additional column in Table 4-2 will be required • REBID response times were used as a basis for discussion • No evaluations times were shortened. It is assumed that all times were developed with good cause. MATCHING evaluation is more complex than REBID evaluation so it should take at least as long.

  18. Matching evaluation Timing recommendation • NF Hourly and Daily times were extended • Firm Monthly times were based on 72 hour best effort from footnote 6 • Superscript indicates calendar days • Amendment to Motion 79 required

  19. Matching Evaluations • A MATCHING request must be evaluated for validity by the TP upon receipt (QUEUED status) • This does not include an AFC/ATC or feasibility evaluation • Feasibility cannot be guaranteed at this point as subsequent higher priority MATCHING requests may be received • The TP has already tested and communicated a minimum MATCHING profile for feasibility • A final evaluation will be performed upon receipt of the final MATCHING response per Motion 58

  20. Matching evaluations recommendation • Option 1: TP indicates validity of a MATCHING request by setting the status from QUEUED to RECEIVED or INVALID. • Expanded use of the RECEIVED state to indicate that the request is being evaluated and that it has passed the validity check • No new status or changes to the state transition diagram required • Option 2: TP indicates validity of a MATCHING request by setting the status from QUEUED/RECEIVED to VALID or INVALID. • Introduces the new status “VALID” • Increases transparency at the cost of complexity

  21. Matching Evaluation Timing Motion 6 Motion 6: “An additional column shall be added to Table 4-2 titled ‘Provider Matching Evaluation Time Limit’. This column shall indicate the time the TP has to respond to the validity of a Matching request. This column shall also indicate the time the TP has to perform all final Matching evaluations and communicate the results once the final Matching response has been received. • NF Hourly<1 hour – N/A • NF Hourly>1 hour–20 minutes • NF Daily – 20 minutes • NF Weekly – 4 hours • NF Monthly – 2 calendar days • Firm Daily <24 hours – N/A • Firm Daily – 4 hours • Firm Weekly – 4 hours • Firm Monthly – 3 calendar days”

  22. Matching evaluationmotion 7 • Motion 7: “There are two TP evaluations of MATCHING requests: one for validity and one for feasibility as follows: • The Transmission Provider shall evaluate each MATCHING request for validity upon receipt. The validity of a MATCHING request shall be indicated by setting the status from QUEUED to RECEIVED. Failure of the validity evaluation shall be indicated by setting the MATCHING request from QUEUED to INVALID. There shall be no requirement to include any AFC, ATC, or feasibility evaluations in this initial evaluation. This evaluation shall adhere to the Provider Matching Evaluation Time Limit which shall be populated in the template element MATCHING_RESPONSE_TIME_LIMIT. • The final evaluation of preemption and competition with ROFR shall adhere to the Provider Matching Evaluation Time Limit which shall be populated in the template element RESPONSE_TIME_LIMIT.”

  23. Matching evaluationmotion 79 amendment • Motion 79 amendment: “The TP shall account for the Tier 2 Defender’s Matching time limit, if applicable, the Challenger’s Confirmation time limit, and the Provider Matching Evaluation Time Limit when determining if the Preemption and Competition process should be initiated as follows…”

  24. Challenger confirmation time limit • When a TSR is issued a COUNTEROFFER they are given time to respond based on Table 4-2. • When a challenger is issued a COUNTEROFFER there are additional concerns. • QUEUE processing delays • Defenders unsure of the final disposition of their request • In order to mitigate these factors, challengers shall receive a modified confirmation time limit • By not opting out the challenger has agreed to the modified time limit • An additional column in Table 4-2 will be required

  25. Challenger confirmation time limit (cont.) • Firm times set to equal the matching confirmation time limit • Footnote 2 will apply. • How will this be handled for Coordinated Requests (footnotes 8 & 9)?

  26. Challenger confirmation time limit motion 8 Motion 8: “An additional column shall be added to Table 4-2 titled ‘Challenger Confirmation Time Limit’. This column shall indicate the time a challenger has to respond (i.e. Confirm or Withdraw) the COUNTEROFFER status. • NF Hourly <1 hour – N/A • NF Hourly >1 hour – 10 minutes • NF Daily – 1 hr • NF Weekly – 2 hr • NF Monthly – 24 hours • Firm Daily <24 hours – N/A • Firm Daily – 24 hours • Firm Weekly – 24 hours • Firm Monthly – 24 hours”

  27. CHALLENGER REBID • The NT assignment recommended offering partial service to NITS challengers. The discussion held was based on the premise that NITS customer should either take the counteroffer or walk away • There should be consistency in treatment of NITS and PTP challengers • Option 1:Challenger REBID removes the challenger from P&C. An inventory only counteroffer will be offered. • Low complexity to implement and no timing implications • Concern is that this is not equitable treatment of customer options

  28. CHALLENGER REBID (CONT.) • Option 2:Reevaluate the challenger after REBID to determine the updated list of defenders and recommended actions • This seems to be the most equitable and consistent treatment of REBID • There are technical hurdles to implementation if the initial eval is used • Challenger may lose their status as a challenger if the initial eval is not used • There are no timing implications due to existing standards for REBID timing • This really comes down to a question of whether the implementation and complexity is worth the value gained.

  29. CHALLENGER REBID (CONT.) • Option 3:Explore modification of Motion 20 • REBID requests can be processed normally • Minimum delay to queue • Is there any possible mitigation to the game Motion 20 was designed to prevent? • Option 4: Block the REBID status for all challengers • Set the competing flag upon identification as challenger. REBID will not be allowed while the competing flag is set. • Low complexity to implement and no timing implications • Can be applied consistently across challengers of any tier

  30. Challenger rebid recommendation • Motion 20 will not be modified • Reevaluation is not recommended as it introduces too much complexity • If a defender is dropped can they elect to keep their match or remaining profile? • Is the provider required to modify the remaining and matching profiles per motion 49? What if the defender has already elected a reduced remaining profile? • Does the defender get a second chance to match? • Does the matching time limit reset? • Option 4 was selected

  31. Challenger rebidmotion 9 • Motion 9: “When a TSR is identified as a challenger the COMPETING_REQUEST_FLAG shall be set to ‘Y’. A status change from COUNTEROFFER to REBID shall not be permitted when the COMPETING_REQUEST_FLAG is set. Once the preemption and /or competition has concluded the COMPETING_REQUEST_FLAG shall be set to ‘N’.”

  32. BINDING THE DEFENDERPRO-BINDING • Modify Motion 20 such that final action may be taken on defenders prior to confirmation of challenger with ROFR • Pros • This option offers the lowest complexity and greatest transparency • Pro-Binding resolves the question “Is it equitable that defenders that did not match get the same unwinding benefit as defenders that did match?” • Eliminates the risk of repeated competitions since nothing changed if do no harm is applied. • The game Motion 20 was put in place to prevent is partially mitigated due to Defender option to match or walk away • Fast resolution to competition. Complete once all matching decisions are received.

  33. BINDING THE DEFENDERPRO-BINDING(CONT.) • Cons • This would result in defenders either losing service or taking additional service while the challenger has no obligation to confirm. • The concept of ‘taking a lot to grant a little’ was addressed in Motion 47. This must be addressed again as Motion 47 does not apply here. Defenders electing a low remaining profile may outweigh the requested extensions by defenders that elect to match. • There is a lack of equity between challenger and defender as the challenger may walk away and the defenders are left in the same position as if the challenger had confirmed • Potential conflict with Motion 36

  34. Binding the challenger • Do not allow a challenger to withdraw if only a counteroffer is available • This is similar to binding the defender as all parties are locked into their decision. • Low complexity and fast • Addresses many of the problems present with binding the defender • The concept of forcing a customer to take any counteroffer was poorly received. It is also in direct conflict with Motion 17.

  35. BINDING THE DEFENDERDO NO HARM • Unwinding of P&C actions will be mandatory. Defenders do not get a choice to keep their match. • This only applies where the challenger counteroffer > 0. • This only applies where the challenger withdraws a counteroffer. • The fundamental principal is that when the challenger is given the option to walk away, no defenders should not be harmed if that option is elected. • If no counteroffer is available due to defenders exercising ROFR then do no harm does not apply.

  36. BINDING THE DEFENDERDO NO HARM (CONT.) • Pros • Fully prevents the game Motion 20 was designed to prevent • No change to existing motions required • Provides equity to defenders vs. challengers • Timing impact is limited to specific condition • Cons • More complex due to the need to undo sandbox actions and creation of an additional “path” to completion of P&C. • Slower completion of P&C. Competition ends once challenger decisions has been made. • There is a risk of repeated identical competitions as the unwind action effectively resets the conditions. • No mitigation will be developed. This is an acceptable risk.

  37. Binding vs. do no harm recommendation • Binding the challenger will not be implemented. There is no support for forcing a customer to blindly accept all counteroffers. • Binding the defender is the superior option from a process and development standpoint. It is the lowest complexity and fastest feasible option. It is fundamentally flawed in that it is fails to prevent gaming and/or disruption to service with no commitment. • Do no harm was selected. The worst outcome of P&C is for CONFIRMED TSRs to lose service for no reason. The increase in complexity and extended timelines are an acceptable cost to prevent this outcome.

  38. Do no harmmotion 10 • Motion 10: “When there is a challenger with ROFR defenders and: • One or more defenders exercise ROFR • The challenger receives a counteroffer >0 • The challenger sets the status to WITHDRAWN or the time limit for confirmation has expired All MATCHING requests shall be set to ANNULLED and all capacity withheld to accommodate the MATCHING requests shall be returned to AFC/ATC inventory. All COMPETING_REQUEST_FLAGs shall be set to ‘N’.”

  39. OPT OUT FLAGS • 2 flags • Opt-out from consideration as a challenger • Opt-out from identifying one’s own TSRs as defenders (Motion 62) • Option 1 • The opt out flag(s) will be a part of the transrequest template and must be elected at the time of submission. • Option 2 • The opt out flag(s) will be available after the TSR is identified as a challenger with ROFR defenders. • Option 3 • There should not be any opt out flags

  40. OPT OUT FLAGSOPTION 1 • Option 1The opt out flag(s) will be a part of the transrequest template and must be elected at the time of submission. • Customers do not like having to opt out without detailed PC information. This is a complex decision that cannot be made up front. The sentiment is that it is important to have this decision available mid-stream after PC is identified. • Changes will be needed for the transrequest and transstatus templates. • This is a straightforward solution. Minimal complexity is added. There are no timing implications to consider.

  41. OPT OUT FLAGSOPTION 2 • Option 2:The opt out flag(s) will be available after the TSR is identified as a challenger with ROFR defenders. • This option provides customers with the most detailed PC information available. • Customer notification must be sent once they are identified as a challenger with ROFR defenders. There would be a provider time limit for this notification. • Notification should include what the COUNTEROFFER would be without P&C • Concern that the challenger may get advance notice of ROFR if they are a defender as well

  42. OPT OUT FLAGSOPTION 2 (CONT.) • Customer will have some time to respond. The customer response will be embedded in the provider evaluation time limit (similar to REBID). • This will effectively reduce the provider evaluation time limit by the time it takes the customer to respond. • This will delay queue processing for the time it takes the customer to respond. *This is an example only

  43. Opt out flagsOther options • Option 3: Explore modification of Motion 20. Challenger must be in final state prior to taking actions on defenders. • Rejected due to gaming opportunities • Option 4: The opt out flag(s) will be available after the TSR is identified as a challenger with ROFR defenders but not further information will be provided. • Rejected as it is not substantially different from Option 1. The customer still does not have the information to make an informed decision.

  44. Opt out flagsRecommendation • Option 1 is the recommended implementation for opt out flags. • This option was selected due its simplicity and transparency. • Option 2 introduces substantial queue processing delays and complexity. • The customer concern that they will not have enough information at the time of submission remains. • All opt out flags will be disabled by default. That is a customer must actively opt out of P&C rather than actively opt in to P&C.

  45. Opt out flagsmotion Motion 1: “The transrequest template shall contain two flags that may be used to modify challenger rights. When set to ‘Y’ WAIVE_CHALLENGE shall waive all rights as a challenger. When set to ‘Y’ WAIVE_CUSTOMER_CHALLENGE shall waive all rights to challenge any TSR if the customer code of the potential defender is equal to the customer code of the submitted TSR. These flags shall be set to ‘N’ by default.”

  46. Worksheet#1e • #1e – “The valid Match has 0’s for the matching profile (see Motion 65) what status does the TP set to indicate that the remaining profile will be accepted. “ • The Transmission provider will set the Matching request to RECEIVED. It will be ACCEPTED/CONFIRMED once all responses have been received and evaluated.

  47. Worksheet#3 • #3 – “Can a Matching request be REBID and/or WITHDRAWN? ” • Matching requests are submitted preconfirmed. • All Matching requests are PTP • Matching requests are set to REFUSED or INVALID for all evaluation failures • Neither status is possible given the conditions and no exception should be made.

  48. Worksheet#7 • #7 – “The Defender puts in a mitigating profile that exceeds the bounds of the maximum remaining profile, what is the correct TP action?” • Committee agreed response: • “The Transmission Provider will set the matching request to INVALID status” • Motion 11: “If the customer submits a MATCHING request in which the remaining profile of capacity over time exceeds the remaining profile provided by the TP, the TP shall respond by setting the MATCHING request status to INVALID.”

  49. Questions?

More Related