Using off-path mechanisms for exposing Time-Variant Routing information
draft-ietf-tvr-off-path-exposure-02

TVR                                                      L. M. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                             20 April 2026
Expires: 22 October 2026

Using off-path mechanisms for exposing Time-Variant Routing information
                  draft-ietf-tvr-off-path-exposure-02

Abstract

   Time-Variant Routing (TVR) involves predictable, scheduled changes to
   network topology elements such as nodes, links, and adjacencies that
   impact routing behavior over time.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  This document proposes mechanisms for
   exposing TVR information to both internal and external applications,
   focusing on off-path solutions that decouple the advertisement of
   scheduled changes from the routing control plane signaling.

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 22 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Contreras                Expires 22 October 2026                [Page 1]
Internet-Draft                Off-path TVR                    April 2026

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  On-path vs Off-path Mechanisms for TVR  . . . . . . . . . . .   4
     2.1.  On-path Mechanisms  . . . . . . . . . . . . . . . . . . .   4
     2.2.  Off-path Mechanisms . . . . . . . . . . . . . . . . . . .   4
     2.3.  Hybrid Approaches . . . . . . . . . . . . . . . . . . . .   5
   3.  Ways of retrieving scheduled topological changes  . . . . . .   5
     3.1.  Interaction with a network controller . . . . . . . . . .   5
     3.2.  Interaction with routing protocols augmented to support TVR
           advertisements  . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Applicability . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Mechanisms for Off-Path Exposure of TVR Information . . . . .   7
     4.1.  ALTO Protocol . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Other Off-path Mechanisms . . . . . . . . . . . . . . . .   9
   5.  Security and operational considerations . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Time-Variant Routing (TVR) refers to operational scenarios where
   network topology, including nodes, links, and adjacency attributes,
   changes in a predictable, scheduled manner.

   There can be operational situations (e.g., maintenance windows, load
   balancing, energy-saving policies, or network upgrades) where changes
   in the network, such as modifications in either nodes, links or
   adjacencies, can introduce variations on the routing of that network.
   Use cases representative of such operational situations are
   documented in [RFC9657].  Those predictable changes can be scheduled
   either from a higher-level system (e.g., OSS) or from a Network
   Controller.  Figure 1 sketches a potential architecture facilitating
   the exposure of changes introduced by TVR operation.  There can be
   multiple variants of such architecture.

Contreras                Expires 22 October 2026                [Page 2]
Internet-Draft                Off-path TVR                    April 2026

        Network             (programming       (impact
        Operator ---------+ of scheduled      estimation
                          | TVR changes)     of scheduled
                          V                  TVR changes)
                   +-------------+       +--------------+
                   |   Network   |       |   Network    |
                   |  Controller |<----->| Digital Twin |
                   +-------------+       +--------------+
                       A     |
   (feeding impacts    |     |        (activation
   of scheduled +------+     +------+ of scheduled
   TVR changes) |                   | TVR changes)
                |                   |
                V                   V
        +-------------+          ,------._
        |Off-path Info|       ,-'         `-.
        |  Component  |      /               \
        +-------------+     (     Network     )
                A            \               /
                |             `-.         ,-'
     (exposure  |                `+------'
   of scheduled |                     ^
   TVR changes) |                     :
                |  (awareness         :
                | of scheduled        v
                | TVR changes) +-------------+
                +------------->| Application |
                               +-------------+

   Figure 1.  Potential architecture using a dedicated Off-path
   Information Component for advertising TVR scheduled changes

   Since the expected changes can be predicted beforehand, then it is
   possible to anticipate the impacts of that changes in the routing of
   the network, for instance by means of algorithms embedded in the
   Network Controller allowing to recalculate the resulting routing
   metrics, or through experimental observations e.g. in network digital
   twins [I-D.irtf-nmrg-network-digital-twin-arch].

   Being feasible then to automatize the changes and to pre-calculate
   the impacts that those changes can introduce into the routing of the
   network, it is possible to expose in advance such changes in a way
   that applications (both internal and external) can become aware of
   those routing variations along time, allowing proactive service
   management and optimization ahead of the activation of those changes.

Contreras                Expires 22 October 2026                [Page 3]
Internet-Draft                Off-path TVR                    April 2026

   This document builds on TVR-related foundational work [RFC9657],
   [I-D.ietf-tvr-requirements] and [I-D.ietf-tvr-schedule-yang], but
   focussing on off-path exposure of TVR information, describing
   architectural considerations and mechanisms to present scheduled
   network changes to applications.

2.  On-path vs Off-path Mechanisms for TVR

   At the time of advertising and consuming TVR scheduled changes, two
   different mechanisms can be considered, namely on-path and off-path
   mechanisms.

2.1.  On-path Mechanisms

   On-path mechanisms disseminate scheduled topological changes directly
   through routing protocols such as OSPF, IS-IS, or BGP, augmented to
   carry time-scheduled advertisements [I-D.ietf-tvr-schedule-yang].
   This approach embeds TVR information on the routing control plane.

   One of the primary benefits of disseminating scheduled topological
   changes by routing protocols is the potential for timely, distributed
   updates.  This tight coupling enables rapid propagation of scheduled
   changes across the network.

   However, this approach also introduces several challenges:

   *  Cascading Updates: a single scheduled change (e.g., link metric
      adjustment or path re-optimization) may trigger a series of
      subsequent updates across the network.  These cascading effects
      can lead to excess of processing in the network elements if not
      properly managed.

   *  Coordination and Conflict Resolution: in a distributed
      environment, multiple nodes may attempt to adjust routes or
      metrics concurrently.  This increases the complexity of
      coordination and requires robust mechanisms to detect and resolve
      conflicts without introducing inconsistencies or loops.

2.2.  Off-path Mechanisms

   Off-path mechanisms expose TVR information via centralized or
   logically separate systems outside the routing protocol control
   plane, using specific protocols, data models or APIs for that
   purpose.

   It can be advantageous for different reasons:

Contreras                Expires 22 October 2026                [Page 4]
Internet-Draft                Off-path TVR                    April 2026

   *  Simplified conflict detection and resolution due to centralized
      control.

   *  Controlled and potentially filtered exposure of information to
      external or internal applications.

   *  Reduced impact on routing protocols and network stability.

   Off-path solutions can ingest data from multiple sources, including
   controllers and augmented routing protocols, and provide aggregated,
   application-friendly views of scheduled network changes.

2.3.  Hybrid Approaches

   Hybrid approaches may combine on-path and off-path methods, e.g.,
   using routing protocol advertisements for internal synchronization
   and off-path systems for external exposure.

3.  Ways of retrieving scheduled topological changes

   According to the two strategies commented in the Introduction, it can
   be considered two different ways in which off-path solutions retrieve
   the information about scheduled topological changes.  In one case,
   the changes can be notified directly by a network controller, while
   in the second case the changes are collected from advertisements in
   augmented routing protocols.

   In both cases, the data model for representing the scheduled changes
   can be the same, describing the changing topological events in a
   similar way.  A data model for representing TVR information is
   proposed in [I-D.ietf-tvr-schedule-yang], which can be used in any of
   the options describe next.

3.1.  Interaction with a network controller

   The architecture in Figure 1 assumes the intervention of a Network
   Controller in order to schedule and activate the changes in the
   network in a predictable manner.  The network controller can pass the
   information about the planned changes to a separate component
   dedicated to advertise the TVR changes off-path, or it could even
   incorporate such capability as part of the functional capabilities of
   the controller.  Thus, depending on the capabilities of the
   controller, it may either provide raw scheduled changes or
   precomputed future topologies reflecting those changes.

Contreras                Expires 22 October 2026                [Page 5]
Internet-Draft                Off-path TVR                    April 2026

3.2.  Interaction with routing protocols augmented to support TVR
      advertisements

   As an alternative solution, it could be the case that existing
   routing protocols become augmented in order to natively support the
   advertisement of network changes along the time (for instance, an
   example of schedules for OSPF costs is provided in
   [I-D.ietf-tvr-schedule-yang]).  If that is the case, the off-path
   solution can participate of the signaling of the network routing
   information by listening to IGPs and/or peering with BGP speakers, as
   described in [RFC7971].  This enables the off-path system to build
   time-aware topological views based on routing advertisements.

3.3.  Applicability

   Uniform representation of scheduled changes facilitates ingestion and
   processing.  The TVR YANG data model [I-D.ietf-tvr-schedule-yang]
   provides a framework to represent schedules for nodes, interfaces,
   and attributes, including timing, periodicity, and availability.

   For instance, an engineer in the Network Operation Center (NOC)
   represented in Figure 1 can program some changes in the network in a
   planned, anticipated way so that the impacts of such changes can be
   estimated in advance.  For instance, the engineer can enter the
   following data, according to [I-D.ietf-tvr-schedule-yang]:

Contreras                Expires 22 October 2026                [Page 6]
Internet-Draft                Off-path TVR                    April 2026

   module: ietf-tvr-node
     +--rw node-schedule
        +--rw node-id? "192.168.10.17"
        ...
        +--rw interface-schedule
           +--rw interfaces*
              +--rw name "GigabitEthernet0"
              ...
              +--rw attribute-schedule
                 +--rw schedules*
                    +--rw schedule-id "0123456789"
                    +--rw (schedule-type)?
                       +--:(period)
                         ...
                          +--rw period-start "2024-07-08T10:30:00"
                          +--rw time-zone-identifier? "Africa/Dakar"
                          +--rw (period-type)?
                             ...
                             +--:(duration)
                                +--rw duration? "3600"
                                     ...
                                     +--rw attr-value
                        +--rw available? "false"

   This order represents the action of tearing down interface
   GigabitEthernet0 of the node with loopback IP address 192.168.10.17
   for one hour, at 10:30 local time of Dakar, due for instance to a
   maintenance action in the network.  With this information, the
   network systems can analyse the impact of such action (the way in
   which that impacts are evaluated are out of scope of this document).
   According to the estimated impacts, the engineer can decide to
   continue or to replan the action.

4.  Mechanisms for Off-Path Exposure of TVR Information

   Exposing TVR information requires mechanisms able to represent time-
   varying network states, including topology and associated metrics,
   with appropriate granularity and temporal precision.

4.1.  ALTO Protocol

   The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285]
   has been designed to expose network topological information and
   associated costs to applications.  In consequence, ALTO can an act as
   an off-path mechanism for the purpose of exposing the impacts due to
   changes in the routing of a network.  In that case, the Off-path
   Information Component in Figure 1 is realized by means of an ALTO
   Server.

Contreras                Expires 22 October 2026                [Page 7]
Internet-Draft                Off-path TVR                    April 2026

   ALTO [RFC7285] provides topological-related information in the form
   of both network and cost maps.  The network map basically summarizes
   the IP address ranges aggregated in each Provider-defined Identifier
   (PID).  Such IP addresses define either customers or service
   functions attached to each network node.  The cost map details the
   topological relationship among PIDs in terms of a certain metric.
   The basic metric provided is the routing cost among PIDs, but other
   metrics can be also provided such as performance-related metrics
   [RFC9439].

   For the purpose of exposing future changes on the reachability
   between PIDs in the network, ALTO defines in [RFC8896] a calendared
   cost map (named ALTO cost calendar) which allows to signal future
   changes on the cost metric.  Thus, for a metric related to routing,
   the cost calendar can expose scheduled modifications in the
   connectivity between PIDs in a natural manner.

   The ALTO cost calendar presents the information (i.e., metrics
   between PIDs) in the form of JSON arrays, where each listed value
   corresponds to a certain time interval.  The ALTO cost calendar also
   includes attributes to describe the time scope of the calendar.  The
   calendar provided by ALTO has the following attributes defined in
   [RFC8896]:

   *  "Calendar-start-time", which indicates the date at which the first
      value of the calendar applies.

   *  "Time-interval-size", that defines the duration of an ALTO
      Calendar time interval in a unit of seconds.

   *  "Number-of-intervals", that indicates the number of values of the
      cost calendar array.

   *  "Repeated", which is an optional attribute that indicates how many
      iterations of the calendar value array have the same values.

   In order to know about cheduled changes, two possibles strategies can
   be in place.

   One strategy is to relay on centralized network control elements
   populating scheduled changes to the ALTO server sufficiently in
   advance as to calculate and expose the intended changes before them
   are effectively activated in the network by the controllers.  That
   is, the introduction of changes is governed by the network controller
   configuring dynamically the network elements (i.e., nodes, links)
   following a planned set of actions.  Such planned actions are the
   ones fed into ALTO so that ALTO can create and expose updated
   topological views for the scheduled modifications.

Contreras                Expires 22 October 2026                [Page 8]
Internet-Draft                Off-path TVR                    April 2026

   A second strategy is to disseminate the scheduled changes by means of
   the routing protocols in the network, so that the routing protocols
   distribute the planned topological changes at link or node level.  It
   is worthy to note that a change distributed in this manner just by a
   single node can motivate a cascade of some other scheduled changes in
   different other nodes, thus representing potential stability issues
   that should be addressed with care.  Anyway, in certain environments
   it can be suitable for signaling scheduled changes so that can serve
   as basis for deriving from it the topological views to be exposed by
   ALTO.

4.2.  Other Off-path Mechanisms

   While ALTO is a mature example, other off-path mechanisms may include
   custom APIs exposing scheduled network data.  Such APIs could be
   supported by;

   *  Network Controllers, in case such controller is able to compute
      and maintain the changes.

   *  Managing device, in charge of generating and maintaining the
      schedules, or Schedule Database as defined in
      [I-D.zdm-tvr-applicability].

5.  Security and operational considerations

   Same security and operational considerations as described in
   [RFC8896] apply also in this document.

   Apart from that, [I-D.ietf-tvr-requirements] describes relevant
   security considerations for TVR solutions.

   The off-path approach prevents some of those security issues, as the
   ones requiring direct access to the source of information in risk,
   like the time synchronization signals.  However, some other threats
   are of applicability, like the ones referring to the access to the
   information, activity identification and privacy.

   In order to mitigate such security risks, the off-path solution
   should implement the necessary mechanisms for authentication, secure
   data transfer and privacy preservation.

6.  References

6.1.  Normative References

Contreras                Expires 22 October 2026                [Page 9]
Internet-Draft                Off-path TVR                    April 2026

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <https://www.rfc-editor.org/info/rfc7285>.

6.2.  Informative References

   [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-08,
              2 March 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tvr-requirements-08>.

   [I-D.ietf-tvr-schedule-yang]
              Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
              Blanchet, "YANG Data Model for Scheduled Attributes", Work
              in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
              08, 9 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
              schedule-yang-08>.

   [I-D.irtf-nmrg-network-digital-twin-arch]
              Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
              Q., Boucadair, M., and C. Jacquenet, "Network Digital
              Twin: Concepts and Reference Architecture", Work in
              Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
              twin-arch-12, 27 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
              network-digital-twin-arch-12>.

   [I-D.zdm-tvr-applicability]
              Zhang, L., Dong, J., and M. Boucadair, "Applicability of
              TVR YANG Data Models", Work in Progress, Internet-Draft,
              draft-zdm-tvr-applicability-05, 9 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-zdm-tvr-
              applicability-05>.

   [OPTIMAIX_repo]
              "OPTIMAIX repository (https://github.com/OPTIMAIX)", n.d..

   [OPTIMAIX_video]
              "Network Operation Demonstration
              (https://www.youtube.com/channel/UC4_sduilyier-cA3-Xpir-
              A)", December 2024.

Contreras                Expires 22 October 2026               [Page 10]
Internet-Draft                Off-path TVR                    April 2026

   [RFC7971]  Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
              S. Previdi, "Application-Layer Traffic Optimization (ALTO)
              Deployment Considerations", RFC 7971,
              DOI 10.17487/RFC7971, October 2016,
              <https://www.rfc-editor.org/info/rfc7971>.

   [RFC8896]  Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N.
              Schwan, "Application-Layer Traffic Optimization (ALTO)
              Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November
              2020, <https://www.rfc-editor.org/info/rfc8896>.

   [RFC9439]  Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
              L. Contreras, "Application-Layer Traffic Optimization
              (ALTO) Performance Cost Metrics", RFC 9439,
              DOI 10.17487/RFC9439, August 2023,
              <https://www.rfc-editor.org/info/rfc9439>.

   [RFC9657]  Birrane, III, E., Kuhn, N., Qu, Y., Taylor, R., and L.
              Zhang, "Time-Variant Routing (TVR) Use Cases", RFC 9657,
              DOI 10.17487/RFC9657, October 2024,
              <https://www.rfc-editor.org/info/rfc9657>.

Acknowledgements

   This work has been partially funded by the Spanish Ministry of
   Economic Affairs and Digital Transformation and the European Union -
   NextGenerationEU under projects OPTIMAIX_OaaS (Ref. TSI-
   063000-2021-34) and OPTIMAIX_NDT (Ref. TSI-063000-2021-35).

Author's Address

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   28050 Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com

Contreras                Expires 22 October 2026               [Page 11]