# Name: Time Variant Routing (TVR)

## Description

Existing routing protocols expect to maintain contemporaneous, end-to-end connected paths across a network. Changes to that connectivity, such as the loss of an adjacent peer, need the routing protocols to react to reduce the impact on the network traffic.

However, a growing number of use cases exist where predicted variations to the topology are an expected part of normal network operations. In these cases, the predicted loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as non-disruptive events.

Predicted changes (restoration, activation, or loss) to links and neighbors can occur for various reasons. For example, in networks with mobile nodes, such as aerial vehicles and some orbiting spacecraft constellations, links can be lost and re-established, or neighbors may change as a function of their mobility. Similarly, network traffic might be routed based on energy costs or
expected user data volumes, which may vary predictably over time in networks prioritizing green computing and energy efficiency. Support for such use cases and expected changes in a routing system is called Time Variant Routing (TVR).

The Time Variant Routing Working Group (TVR WG) is chartered to define solutions that address time-based, scheduled changes to a network. Time-based changes may include changes to links, adjacencies, traffic volumes, and cost. Solutions are expected to leverage existing IETF-defined protocols and mechanisms where possible. The WG may also define terminology and concepts where needed, as well as address the impacts of a continually changing topology on the hierarchical structure of the network.

The TVR WG will provide its outputs for consideration by other Routing Area Working Groups, which may use the material to incorporate time-variant attributes and behaviors into individual protocols.

Specifically, the TVR WG will work on these items:

(1) Problem Statement and Use cases

This document (or set of documents) should include a description of the problem statement and related use cases to guide the remaining work.

This document may not necessarily be published as an IETF Stream RFC but may be maintained in draft form to support the efforts of the Working Group and help newcomers.

(2) Requirements

This document should include definitions, requirements, notes, rationales, and examples.

(3) Information Model

This document (or set of documents) should describe the attributes needed to enable routing and forwarding decisions in the presence of time-variant network parameters.

(4) Data Model

YANG Data Model(s) based on the Information Model above.

(5) Applicability Statement

This document should provide an applicability statement on how the models may be used, along with required ancillary IETF technology, to solve the use cases and requirements.

(6) Implementation and Operational Considerations

This document should provide advice and guidance to implementors and operators.


## Milestones

Jul/2023 - Problem Statement and Use cases

Nov/2023 - Requirements

Mar/2024 - Information Model

Jul/2024 - YANG module

Jul/2024 - Applicability Statement

Jul/2024 - Implementation and Operational Considerations