UC-23: L2VPN Scheduling with Past `end_time`

[lmarinve]

Use Case 23: User Submits a Request with Scheduling and end_time Has Already Passed

Domain: User Requests & Scheduling
Component(s): SDX Controller, Meican

---

Trigger

A user submits an L2VPN provisioning request with an end_time that is in the past (e.g., due to a delay, form error, or invalid scheduling input).

---

Expected Behavior

SDX Controller:

• Validate the end_time field on submission
• If end_time is in the past:
  • Reject the request as invalid with a descriptive error: "End time must be in the future."
  • Do not provision or forward the request to OXPO
• If an active L2VPN reaches its scheduled end_time:
  • Automatically mark the service as Removed or Expired
  • Trigger cleanup procedures (send breakdowns to OXPO if applicable)
  • Log the expiration and send notification to the user

Meican:

• Prevent users from submitting expired schedules
• Update service status as Expired or Removed once end_time is reached
• Disable modification of expired services

---

Discussion

• If the L2VPN was valid but expired during submission delay (e.g., by seconds), allow configurable grace period?
• Required coordination with time-based monitoring or scheduler to enforce expiration
• Consideration needed for whether expired services should be retained in history or archived

---

Test Coverage

Planned test: test_23_l2vpn_schedule_endtime_expired.py
This test validates:

• Proper rejection of expired L2VPN requests
• Correct cleanup of active L2VPNs whose end_time has passed
• Accurate status update in Meican and logs

---

Project Reference

• Project 16 – AtlanticWave-SDX E2E Use Cases

---