TVR                                                      L. M. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                          23 December 2024
Expires: 26 June 2025


        Using ALTO for exposing Time-Variant Routing information
                    draft-ietf-tvr-alto-exposure-00

Abstract

   Network operations can require time-based, scheduled changes in
   nodes, links, adjacencies, etc.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  Existing IETF solutions like ALTO can
   assist, as an off-path mechanism, on the exposure of such predicted
   changes to both internal and external applications then anticipating
   the occurrence of routing changes.  This document describes how ALTO
   helps in that purpose.

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 26 June 2025.

Copyright Notice

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










Contreras                 Expires 26 June 2025                  [Page 1]

Internet-Draft                ALTO for TVR                 December 2024


   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.  Capabilities of ALTO for exposing information . . . . . . . .   4
     2.1.  ALTO exposed information  . . . . . . . . . . . . . . . .   4
     2.2.  Mechanism for anticipating routing changes in ALTO  . . .   5
   3.  Ways of retrieving scheduled topological changes  . . . . . .   5
     3.1.  Interaction with a network controller . . . . . . . . . .   6
     3.2.  Interaction with routing protocols augmented to support TVR
           advertisements  . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Applicability . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Assessment of ALTO as off-path solution against TVR
           requirements  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Implementation status . . . . . . . . . . . . . . . . . . . .   9
   6.  Identified gaps . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security and operational considerations . . . . . . . . . . .   9
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Assessment of archietcture proposed in
           I-D.wqb-tvr-applicability . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   There can be operational situations 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.

   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].





Contreras                 Expires 26 June 2025                  [Page 2]

Internet-Draft                ALTO for TVR                 December 2024


   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.

   Current IETF solutions like ALTO [RFC7285] have been conceived for
   exposing topological information with associated metrics.  In
   consequence, ALTO can be perceived as a suitable piece allowing to
   expose the impacts due to changes in the routing of a network.
   Figure 1 sketches a potential architecture facilitating the exposure
   of changes introduced by TVR operation.  There can be multiple
   variants of such architecture.

        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
           +--------+            ,------._
           |  ALTO  |         ,-'         `-.
           | Server |        /               \
           +--------+       (     Network     )
                A            \               /
                |             `-.         ,-'
     (exposure  |                `+------'
   of scheduled |                     ^
   TVR changes) |                     :
                |  (awareness         :
                | of scheduled        v
                | TVR changes) +-------------+
                +------------->| Application |
                               +-------------+

   Figure 1.  Potential architecture using ALTO for TVR







Contreras                 Expires 26 June 2025                  [Page 3]

Internet-Draft                ALTO for TVR                 December 2024


   ALTO can act as an off-path mechanism for exposing scheduled
   topological changes.  It permits different strategies at the time of
   working with time-based topological variations due to changes
   affecting nodes, links, adjacencies, or metrics.

   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 topological changes
   before those changes 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 to ALTO so that ALTO can create and
   expose updated topological views for the scheduled modifications.

   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.

2.  Capabilities of ALTO for exposing information

2.1.  ALTO exposed information

   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].

   Because of the possibility of incorporating additional metrics and a
   variety of topological information, ALTO can be considered as a
   generic IETF network exposure function [I-D.contreras-alto-ietf-nef].








Contreras                 Expires 26 June 2025                  [Page 4]

Internet-Draft                ALTO for TVR                 December 2024


2.2.  Mechanism for anticipating routing changes in ALTO

   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.

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 ALTO retrieves 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 to be defined for representing the
   scheduled changes can be the same, so representing the changing
   topological events in a similar way.  An example of a potential data
   model representing scheduled changes is proposed in
   [I-D.ietf-tvr-schedule-yang].  A model like that could serve the same
   purpose in any of the options describe next.








Contreras                 Expires 26 June 2025                  [Page 5]

Internet-Draft                ALTO for TVR                 December 2024


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 the ALTO server, so that the
   ALTO server can calculate the future topological map (in terms of
   network and cost maps provided by ALTO).  Alternatively, if the
   network controller has the means of doing so, the network controller
   could even pass the future topology to ALTO.  In any case, with the
   different topological representations, ALTO can expose the current
   and future views in a time-based manner leveraging on the cost
   calendar feature.

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, ALTO can
   participate of the network routing information by listening to IGPs
   and/or peering with BGP speakers, as described in [RFC7971].

3.3.  Applicability

   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 26 June 2025                  [Page 6]

Internet-Draft                ALTO for TVR                 December 2024


   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.  Assessment of ALTO as off-path solution against TVR requirements

   The Time Variant Routing requirements are being documented in
   [I-D.ietf-tvr-requirements].  Despite that is yet a work in progress,
   it is convenient to start an assessment of the off-path solution
   provided by ALTO against the requirements expected to be supported by
   any TVR-capable solution.

   The following Table summarizes the assessment exercise.  The
   requirements are listed including the section (in brackets) of
   [I-D.ietf-tvr-requirements] where they are defined.







Contreras                 Expires 26 June 2025                  [Page 7]

Internet-Draft                ALTO for TVR                 December 2024


     +===============================+===============================+
     | Requirement                   | Compliance                    |
     +===============================+===============================+
     | (3.1) Resource scheduling     | Feasible to reflect scheduled |
     |                               | changes in a topology by means|
     |                               | of a sequence of network and  |
     |                               | cost maps along the time      |
     +-------------------------------+-------------------------------+
     | (3.2.1) Scope of Time-        | Combines both time-invariant  |
     | Variability                   | and time-variant entities.    |
     |                               | Allows representation of      |
     |                               | global and individual changes |
     +-------------------------------+-------------------------------+
     | (3.2.2) Time Horizon          | Specified by means of         |
     |                               | "time-interval-size" attribute|
     |                               | expressed in seconds          |
     +-------------------------------+-------------------------------+
     | (3.2.3) Time Precision        | Determined in units of seconds|
     +-------------------------------+-------------------------------+
     | (3.2.4) Validity in a Schedule| Permits to accommodate        |
     |                               | multiple subsequent schedules |
     +-------------------------------+-------------------------------+
     | (3.2.5) Periodicity in a      | Repetitive states specified   |
     | Schedule                      | by  means of the attribute    |
     |                               | "repeated"                    |
     +-------------------------------+-------------------------------+
     | (3.2.6) Continuity in a       | Governed by the               |
     | Schedule                      | "time-interval-size" attribute|
     |                               | expressed in seconds          |
     +-------------------------------+-------------------------------+
     | (3.2.7) Time-Overlap and      | Not supported. It would       |
     | Priority                      | require extension of RFC8896  |
     +-------------------------------+-------------------------------+
     | (3.2.8) Property Value        | Zero-order hold mode. Other   |
     | Interpolation                 | modes could be potentially    |
     |                               | supported                     |
     +-------------------------------+-------------------------------+
     | (3.2.9) Changes to Model      | Support of fine-grained       |
     | State                         | changes                       |
     +-------------------------------+-------------------------------+
     | (3.3) Topologies              | Schedules applicable to nodes |
     |                               | and links. Support of         |
     |                               | potential future node or link |
     |                               | connectivity                  |
     +-------------------------------+-------------------------------+
     | (3.4) Routing                 | Allows computation of         |
     |                               | TVR-enabled paths. Reported   |
         |                               | constrains can be considered  |



Contreras                 Expires 26 June 2025                  [Page 8]

Internet-Draft                ALTO for TVR                 December 2024


     +-------------------------------+-------------------------------+

5.  Implementation status

   There is an ongoing implementation of the architecture proposed in
   Figure 1, being work-in-progress and not yet publicly available.

   This section will report the implemented features and provide the
   repository of the code targeting IETF 122.

6.  Identified gaps

   The work carried out for implementing the architecture in Figure 1
   reveals some gaps.

   *  [I-D.ietf-tvr-schedule-yang] only provides granularity for
      schedule changes at node and link level.  However, operational
      scenarios as the one described here can require further
      granularity, as cards.  A current workaround could be to count all
      the interfaces of the same card, which can be onerous in some
      cases (e.g., cards of 48 GigaEthernet ports).

   *  Advertisements of scheduled changes in distributed manner (that
      is, on-path, directly using augmented routing protocols) can raise
      conflicts.  While conflicts are easy to handle by centralized
      (i.e., off-path) solutions, it can require the definition of
      arbitration mechanisms for distributed ones.

   *  There are no means defined for reverting planned changes other
      than reconfiguring when distributed advertisements are in place.
      Centralized approach simplifies the evaluation of impacts, and
      then, facilitates the indetification of potential problems that a
      planned change can cause.  Distributed means of distributed
      scheduled changes can require ways of easily reverting proposed
      changes.

   *  When using distributed advertisement, the exposure of planned
      changes to external parties or applications can be a security
      problem, because the potential accessibility to information beyond
      the topological changes.  Secure ways of accessing to that
      information can be needed to allow such use cases.

   Further gaps, if any, will be reported here.

7.  Security and operational considerations

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



Contreras                 Expires 26 June 2025                  [Page 9]

Internet-Draft                ALTO for TVR                 December 2024


   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.

8.  Informative References

   [I-D.contreras-alto-ietf-nef]
              Contreras, L. M., "Considering ALTO as IETF Network
              Exposure Function", Work in Progress, Internet-Draft,
              draft-contreras-alto-ietf-nef-01, 11 July 2022,
              <https://datatracker.ietf.org/doc/html/draft-contreras-
              alto-ietf-nef-01>.

   [I-D.ietf-tvr-requirements]
              King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR
              (Time-Variant Routing) Requirements", Work in Progress,
              Internet-Draft, draft-ietf-tvr-requirements-04, 13
              September 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-tvr-requirements-04>.

   [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-
              03, 20 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
              schedule-yang-03>.

   [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-08, 16 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
              network-digital-twin-arch-08>.






Contreras                 Expires 26 June 2025                 [Page 10]

Internet-Draft                ALTO for TVR                 December 2024


   [I-D.wqb-tvr-applicability]
              Zhang, L., Ma, Q., Wu, Q., and M. Boucadair,
              "Applicability of YANG Data Models for Scheduling of
              Network Resources", Work in Progress, Internet-Draft,
              draft-wqb-tvr-applicability-00, 10 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-wqb-tvr-
              applicability-00>.

   [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>.

   [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>.

Appendix A.  Assessment of archietcture proposed in
             [I-D.wqb-tvr-applicability]

   [I-D.wqb-tvr-applicability] introduces an archietcture for the
   control scheduling of network resources, with two functional
   components, namely the Scheduled Service Requester, in charge of
   soliciting a resource schedule change, and the Scheduled Service
   Responder, in charge of handling the scheduling orders.  Such
   architecture assumes the existence of funcitonal interfaces between
   both comoponents.





Contreras                 Expires 26 June 2025                 [Page 11]

Internet-Draft                ALTO for TVR                 December 2024


   Comparing such architecture with the one depicted in Figure 1, the
   following mapping is possible, as represented in Figure 2.

          Network Operator         (programming       (impact
         [ScheduleRequester]-----+ of scheduled      estimation
                                 | TVR changes)     of scheduled
        .......................  V  ............... TVR changes) ...
        : [Schedule       +-------------+       +--------------+   :
        :  Service        |   Network   |       |   Network    |   :
        : Responder]      |  Controller |<----->| Digital Twin |   :
        :                 +-------------+       +--------------+   :
        :                     A ... | .............................:
        : (feeding impacts    | :   |        (activation
        : of scheduled +------+ :   +------+ of scheduled
        : TVR changes) |        :          | TVR changes)
        :              |        :          |
        :              V        :          V
        :         +--------+    :       ,------._
        :         |  ALTO  |  ..:    ,-'         `-.
        :         | Server |  :     /               \
        :         +--------+  :    (     Network     )
        :              A      :     \               /
        :............. | .....:      `-.         ,-'
            (exposure  |                `+------'
          of scheduled |                     ^
          TVR changes) |                     :
                       |  (awareness         :
                       | of scheduled        v
                       | TVR changes) +-------------+
                       +------------->| Application |
                                      +-------------+
                                    [Schedule Consumer]

   Figure 2.  Schedule Requester, Responder and Consumer in the off-path
   solution

   From this assessment, it can be concluded that the roles of Schedule
   Requester and Schedule Responder have its correspondance in the off-
   path solution here described.  However, the intended architecture in
   [I-D.wqb-tvr-applicability] lacks of the role of Schedule Consumer
   here described (or at least assumes that the Requester will be also
   the Consumer, which cannot be necessarily the case).









Contreras                 Expires 26 June 2025                 [Page 12]

Internet-Draft                ALTO for TVR                 December 2024


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 26 June 2025                 [Page 13]