TVR L. M. Contreras Internet-Draft Telefonica Intended status: Informational 23 June 2026 Expires: 25 December 2026 Time-Variant Routing Scheduling for Interconnection Scenarios draft-contreras-tvr-interco-scheduling-00 Abstract This document specifies the applicability of Time-Variant Routing (TVR) information in interconnection scenarios. In particular, it discusses how scheduled changes affecting BGP sessions, routing policies, and effective interconnection capacity between administrative domains can be applied. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Contreras Expires 25 December 2026 [Page 1] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Maintenance-Aware Peering . . . . . . . . . . . . . . . . 4 4.2. Traffic Engineering Optimization . . . . . . . . . . . . 5 4.3. Energy-Aware Interconnect . . . . . . . . . . . . . . . . 5 4.4. Multi-provider Coordination . . . . . . . . . . . . . . . 5 4.5. SLA-aware Transit Adjustment . . . . . . . . . . . . . . 6 5. Schedule Object for Interconnection . . . . . . . . . . . . . 6 6. Information Exchange Models . . . . . . . . . . . . . . . . . 7 6.1. Off-path Model . . . . . . . . . . . . . . . . . . . . . 8 6.2. In-band Model . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Hybrid Model . . . . . . . . . . . . . . . . . . . . . . 8 7. Operational Considerations . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Existing inter-domain routing operations between administrative domains are mainly reactive. Thus, when a peering session, interconnection, or associated routing policy changes, remote domains usually become aware of the event only when BGP behavior changes or when humans coordinate through operational channels. The Time-Variant Routing (TVR) model [I-D.ietf-tvr-schedule-yang] defines a mechanism to describe scheduled changes in network resources (such as nodes and topology) as a function of time. Such kind of planned changes could apply to interconnection scenarios. For instance, for inter-domain maintenance actions on the BGP sessions established among different adiministrative domains, but also for anticipating the establishment of new interconnection points with their corresponding seesions. Thus, enabling these signaling mechanisms can assist on the automation of zero-touch operations associated to interconnecting networks with different degrees of dynamicity. Those mechanisms provide a potential realization of time-aware interconnection coordination. Different scenarios can be benefited by the announcement of planned changes in interconnection: Contreras Expires 25 December 2026 [Page 2] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 * Public peering, directly between network operators or through neutral internet exchanges. * Transit interconnections among carriers. * Private interconnections where an API-based exchange model is available * Planned changes affecting eBGP sessions between distinct administrative domains. * Dynamic composition and coordinated operation of multi-domain networks enabling the concept of Network of Networks (NoN) (for instance for disaster recovery). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174]. In addition, the terms defined in [I-D.ietf-tvr-requirements] are also used in this document. 3. Problem Statement The current operational toolbox for inter-domain operations is limited. [RFC8326] defines the well-known BGP community GRACEFUL_SHUTDOWN to signal graceful shutdown of paths. It describes operational procedures to reduce traffic loss during planned maintenance. That mechanism is useful immediately before session shutdown, but it does not provide a general framework for long-horizon schedule advertisement, multi-event planning, or distribution of future routing changes. Similarly, Peering API [I-D.ietf-grow-peering-api] defines a standard API to request public peering, verify the status of a request or BGP session, and list potential connection locations, using PeeringDB OIDC for authentication. However, the API does not define support for future scheduled routing events. This document describes the applicability, requirements, and architectural considerations for signaling planned changes on interconnection sessions so that the involved administrative domains can anticipate actions in each respective domain to accomodate to Contreras Expires 25 December 2026 [Page 3] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 traffic variations due to the aforementioned changes. The introduction of scheduled topology and routing attributes enriches the interconnection by enabling networks to anticipate and proactively manage predictable changes rather than react to them after they occur. In environments where planned topology variations are increasingly common, time-aware routing allows systems to pre- compute alternate paths and significantly reduce the convergence impact traditionally associated with such events. This capability directly supports the coordination of traffic engineering decisions across Autonomous System boundaries, overcoming the current limitations of loosely coupled inter-domain policies and improving overall routing efficiency. Furthermore, by allowing routing behaviour to be aligned with known maintenance windows or capacity changes, operators can minimise disruption, avoid unnecessary traffic loss during maintenance operations, and ensure more predictable network performance. This results in improved SLA compliance, as traffic can be steered in advance towards paths that are expected to meet performance requirements, rather than reacting to degradation after it has already impacted services. Finally, the ability to express time-based routing policies introduces a new dimension of control, enabling networks to dynamically adapt routing decisions based not only on topology and metrics but also on temporal conditions, thus paving the way for more automated, predictable, and resilient inter-domain operations. 4. Use Cases A number of use cases illustrate the convenience of this approach. 4.1. Maintenance-Aware Peering This use case describes a planned maintenance scenario in an inter- domain environment, where an operator announces in advance the scheduled shutdown of a peering session at a future time T. The key parameters involved include the temporal information associated with the event (i.e., the planned shutdown time) and the traffic engineering control variables used by remote Autonomous Systems, specifically the adjustment of local preference and the redistribution of traffic across alternative paths. By leveraging TVR mechanisms to expose this scheduled change ahead of time, remote ASes can proactively adapt their routing policies, progressively shifting traffic away from the affected session before the actual shutdown occurs. As a result, traffic continues to be forwarded through valid alternative paths at all times, avoiding packet loss at the moment of shutdown and ensuring service continuity, which directly contributes to improved network stability and SLA compliance. Contreras Expires 25 December 2026 [Page 4] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 4.2. Traffic Engineering Optimization This use case describes a dynamic planned capacity management scenario in an inter-domain environment, where operators proactively announce scheduled network conditions, such as temporary capacity reduction during peak hours and policy changes applied during predefined congestion windows. The key parameters involved include the temporal scope of the event (e.g., peak hours or congestion intervals), the nature of the constraint (capacity limitation or policy adjustment), and the traffic engineering levers available at the receiving AS, notably path selection decisions and prefix-level filtering policies. By leveraging TVR mechanisms to advertise these scheduled conditions in advance, peer networks can adapt their routing strategies proactively, selectively steering traffic toward alternative paths, deprioritising affected routes, or filtering specific prefixes to reduce load on constrained interconnection points. As a result, operators can maintain better service quality during peak periods, enhance SLA adherence, and enable more predictable and policy-driven inter-domain traffic behaviour. 4.3. Energy-Aware Interconnect This use case describes an energy-aware inter-domain optimization scenario, where operators schedule the deactivation of selected inter-domain links during predefined low-traffic periods. The key parameters involved include the temporal definition of the event (i.e., the low-demand time window), the set of affected interconnection links, and the traffic engineering behaviour at the receiving AS, notably the proactive shifting of traffic to alternative available paths. By leveraging TVR mechanisms to advertise these scheduled changes in advance, peer networks can anticipate the temporary reduction in available connectivity and gradually reroute traffic before the link deactivation takes place. This proactive coordination ensures that traffic is continuously forwarded through valid paths, avoiding abrupt changes or transient congestion. In addition to preserving service continuity, this approach enables operators to intentionally consolidate traffic onto a reduced set of links during off-peak periods, supporting energy efficiency and resource optimization objectives. 4.4. Multi-provider Coordination This use case describes a multi-homed customer network scenario, where an enterprise or operator connected to multiple upstream providers receives scheduled routing and topology information from each of its peers. The key parameters involved include the set of schedules advertised by upstream providers (covering events such as maintenance, capacity changes, or policy adjustments over time), and Contreras Expires 25 December 2026 [Page 5] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 the decision process within the customer network, which computes optimal routing strategies for each time interval based on the aggregated information. The customer network can integrate these time-dependent inputs into its routing logic, selecting the most appropriate upstream path dynamically according to predicted conditions rather than reacting to real-time events. This enables the network to optimize path selection across different time windows—balancing performance, cost, or reliability—while avoiding abrupt changes or suboptimal routing decisions during transitions. 4.5. SLA-aware Transit Adjustment This use case describes a maintenance-aware inter-domain routing scenario in which a transit provider advertises, in advance, a reduced availability window affecting part of its infrastructure during planned maintenance. The key parameters involved include the temporal information defining the maintenance window, the scope of the reduced availability (e.g., affected links or capacity constraints), and the policy-driven routing decisions at the customer network, particularly the adjustment of path selection for critical services. With this, the customer network can proactively adapt its routing behaviour, prioritizing alternative upstream paths that ensure the required service levels for latency- or availability- sensitive traffic. This preemptive adjustment avoids relying on reactive convergence triggered by degraded or unavailable paths, thereby minimizing the risk of service disruption. As a result, critical services can maintain consistent performance throughout the maintenance period, improving overall network resilience and strengthening SLA compliance through predictable and controlled routing behaviour. 5. Schedule Object for Interconnection In the context of inter-domain interconnection, a schedule object represents a time-bound description of a planned event that may affect routing behaviour, connectivity, or traffic engineering decisions across Autonomous Systems. This object provides a structured way to describe predictable changes and enables receiving domains to anticipate and adapt their routing policies accordingly. A schedule object is composed of the following key elements: Contreras Expires 25 December 2026 [Page 6] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 * Event Type: identifies the nature of the scheduled event. Typical values include, but are not limited to, maintenance operations (e.g., session shutdown), capacity changes (e.g., temporary link degradation), or policy modifications (e.g., traffic shaping rules during congestion periods). * Affected Entity: specifies the network element or resource impacted by the event. This may refer to a BGP session, a set of prefixes, a specific interconnection link, or a broader inter- domain relationship. * Time Interval: defines the temporal boundaries of the event, including Start Time, as the instant at which the scheduled condition becomes active, and End Time, as the instant at which the condition ceases to apply. These timestamps enable deterministic activation and deactivation of routing behaviours. * Scope: indicates the level at which the event applies. This may include session-level scope (e.g., a specific peering), prefix- level scope (e.g., a subset of routes), or AS-level scope (e.g., all interconnections with a given domain). The scope determines how widely the scheduling information influences routing decisions. * Suggested Action: describes the intended or recommended response to the event. Examples include reducing preference for affected paths, rerouting traffic via alternative paths, or applying filtering policies. The specific enforcement mechanism is left to local policy, and such actions are not mandatory but serve as guidance for coordinated behaviour. The schedule object is designed to be extensible and adaptable to different interconnection scenarios. It enables structured exchange of time-aware information while allowing receiving domains to retain full control over how such information is interpreted and enforced according to local policies. 6. Information Exchange Models Three different ways of exchanging time-aware information are considered. Contreras Expires 25 December 2026 [Page 7] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 6.1. Off-path Model In the off-path model, time-aware scheduling information is exposed through external interfaces such as APIs (e.g., [I-D.ietf-grow-peering-api]), decoupled from the routing protocol itself. In this approach, operators publish schedule data—covering events such as maintenance, capacity changes, or policy modifications—via dedicated platforms that can be consumed by peer networks or external applications. This model aligns with [I-D.ietf-tvr-off-path-exposure], where time- dependent information is disseminated outside the routing control plane and subsequently used to influence routing decisions locally. The off-path model enables integration with orchestration systems, while keeping the routing protocol unchanged. (Note: further work is required in GROW WG to define API extensions). 6.2. In-band Model The in-band model consists of extending BGP to natively carry time- aware scheduling information as part of its control plane exchanges. In this approach, routing updates would include additional attributes encoding scheduled events, enabling routers to directly process temporal information alongside traditional reachability data. (Note: further work is required in IDR WG to define encoding and propagation rules). 6.3. Hybrid Model The hybrid model combines elements of both off-path and in-band approaches to achieve a balance between flexibility and operational simplicity. In this model, schedule information is distributed off- path using APIs (like [I-D.ietf-grow-peering-api]), while enforcement and execution of routing changes are carried out using existing BGP mechanisms. For example, a network may receive advance schedule information externally and then apply local policy actions such as adjusting local preference or leveraging mechanisms like Graceful Shutdown [RFC8326] to steer traffic accordingly. 7. Operational Considerations The introduction of time-based scheduling information into inter- domain routing requires careful consideration of several operational aspects to ensure predictable and stable network behaviour. Contreras Expires 25 December 2026 [Page 8] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 A fundamental requirement is the alignment of timing semantics across domains. Since routing decisions depend on the activation and expiration of scheduled events, all participating systems MUST operate with a consistent time reference. Mechanisms such as NTP or PTP SHOULD be used to ensure that all nodes share a common notion of time, enabling correct and coordinated execution of time-dependent actions. (Note: to check feasibility of this, or any other alternative). The granularity and scope of scheduled events also play a critical role. Fine-grained scheduling (e.g., per-prefix or per-session events) increases flexibility but may introduce higher computational and operational complexity. The introduction of time-based scheduling information in inter-domain environments may lead to situations where conflicting inputs or policy inconsistencies arise. This could be the case of multiple upstream providers advertising contradictory scheduling information, or conflicts with local policies that could require mechanisms for policy validation and override. Proper conflict resolution mechanisms are therefore required to ensure predictable and stable routing behaviour. Furthermore, systems MUST account for failure handling and fallback behaviour. Situations such as missed updates, synchronization errors, or unexpected network changes may invalidate the assumptions underlying scheduled routing decisions. In such cases, implementations SHOULD revert safely to standard routing behaviour, ensuring that connectivity is preserved even if scheduled information cannot be applied as intended. The scalability and state management implications of maintaining time-dependent routing information MUST also be considered. Storing and processing multiple future states of routing policies can increase memory and CPU requirements. Finally, it should be noted that if a domain does not support the time-aware scheduling in the interconnection the expected behavior is the same as today, that is, reactive behavior. 8. Security Considerations The introduction of time-based scheduling information into inter- domain routing environments raises several security considerations that MUST be carefully addressed to prevent misuse and ensure operational trustworthiness. A primary concern is the authentication of schedule sources, as receiving Autonomous Systems MUST be able to verify that scheduling information originates from a legitimate and Contreras Expires 25 December 2026 [Page 9] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 authorized peer. Without strong authentication mechanisms, malicious actors could inject false scheduling data, leading to unintended routing behaviour. Closely related to this is the integrity of schedule information, since any modification of scheduling attributes in transit could result in incorrect routing decisions. Ensuring that schedule data is protected against tampering is therefore essential to maintain the correctness of routing policies derived from such information. Another critical risk is the potential for traffic manipulation through false or misleading schedules. An attacker could exploit time-based attributes to influence traffic engineering decisions across domains, for example by artificially diverting traffic away from certain paths or toward congested or compromised infrastructure. This threat is particularly relevant given that scheduled information is intended to proactively influence routing decisions. Furthermore, the exchange of scheduling information inherently extends across trust boundaries between Autonomous Systems, where policy control and administrative authority are independent. As such, each receiving domain MUST treat externally provided schedule data as untrusted input and apply appropriate validation and policy enforcement mechanisms before acting upon it. To mitigate these risks, the use of secure transport and data protection mechanisms is RECOMMENDED. In particular, mechanisms such as TLS for communication channels, cryptographic signing of schedule data, and the use of secure and authenticated API for off-path information exchange can significantly enhance the trust model. Additionally, implementations SHOULD include policy controls to limit the scope and impact of external scheduling information, ensuring that routing decisions remain aligned with local operational policies and security requirements. 9. Informative References [I-D.ietf-grow-peering-api] Aguado, C., Griswold, M., Ramseyer, J., Servin, A., Strickx, T., and Q. Misell, "Peering API", Work in Progress, Internet-Draft, draft-ietf-grow-peering-api-01, 4 July 2025, . Contreras Expires 25 December 2026 [Page 10] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 [I-D.ietf-tvr-off-path-exposure] Contreras, L. M., "Using off-path mechanisms for exposing Time-Variant Routing information", Work in Progress, Internet-Draft, draft-ietf-tvr-off-path-exposure-02, 20 April 2026, . [I-D.ietf-tvr-requirements] King, D., Contreras, L. M., Sipos, B., and L. Zhang, "Time-Variant Routing (TVR) Requirements", Work in Progress, Internet-Draft, draft-ietf-tvr-requirements-09, 12 June 2026, . [I-D.ietf-tvr-schedule-yang] Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. Blanchet, "A YANG Data Model for Scheduled Attributes", Work in Progress, Internet-Draft, draft-ietf-tvr-schedule- yang-12, 10 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8326] Francois, P., Ed., Decraene, B., Ed., Pelsser, C., Patel, K., and C. Filsfils, "Graceful BGP Session Shutdown", RFC 8326, DOI 10.17487/RFC8326, March 2018, . Acknowledgements This work has been partially funded by the European Commission Horizon Europe SNS JU project and FLECON-6G (GA 101192462). Author's Address Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n 28050 Madrid Spain Contreras Expires 25 December 2026 [Page 11] Internet-Draft Time-Variant Routing Scheduling for Inte June 2026 Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com Contreras Expires 25 December 2026 [Page 12]