TVR L. M. Contreras Internet-Draft Telefonica Intended status: Informational 3 March 2025 Expires: 4 September 2025 Using ALTO for exposing Time-Variant Routing information draft-ietf-tvr-alto-exposure-01 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 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras Expires 4 September 2025 [Page 1] Internet-Draft ALTO for TVR March 2025 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 . . . . . . . . . . . 10 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Assessment of archietcture proposed in I-D.wqb-tvr-applicability . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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 4 September 2025 [Page 2] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 3] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 4] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 5] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 6] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 7] Internet-Draft ALTO for TVR March 2025 +===============================+===============================+ | 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 4 September 2025 [Page 8] Internet-Draft ALTO for TVR March 2025 +-------------------------------+-------------------------------+ 5. Implementation status The scenario proposed in Figure 1 has been implemented for the validation of the off-path TVR approach. The use case to exercise the off-path solution considers operational tasks in the network such as hardware and/or software maintenance and upgrades. Such actions imply temporal topological changes that can be anticipated since they are planned interventions in teh network. By leveraging on TVR, applications consuming the network can be timnely informed of those changes in advanced, permitting re-configurations and re- optimizations on the application side minimizing negative impacts due to the foreseen changes. A video demonstrating the scenario can be found in [OPTIMAIX_video]. The modules implementing the functionality have been released as open source and are available at [OPTIMAIX_repo]. * Network Operation Center (NOC), developed by E-lighthouse. This component is represented as the "Network Operator" in Figure 1. It is in charge of requesting scheduled changes in the network. * Net2plan_NDT, developed by E-lighthouse. This component is part of the "Network Digital Twin" module in Figure 1. It is in charge of performing advanced network simulations and reporting Key Performance Indicator (KPI) evaluation consequence of the topological changes. * Change_Scheduler, devoloped by Telefónica. This component is part of the "Network Controller" module in Figure 1. It is in charge of receiving the topological changes requests, including the intended execution time for the scheduled changes. It passess / receive topological information and KPIs to / from Net2plan_NDT. It is also in charge of triggering the execution of the network chages at due time. * ALTO_CostCalendar, developed by Telefónica. This component is part of the "ALTO Server" module in Figure 1. It is in charge of processing the predicted KPIs on the topology with the proposed changes, and exposing those changes to external applications as an example of off-path mechanism. 6. Identified gaps The work carried out for implementing the architecture in Figure 1 reveals some gaps. Contreras Expires 4 September 2025 [Page 9] Internet-Draft ALTO for TVR March 2025 * [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 be handled by centralized (i.e., off-path) solutions, it can require the definition of arbitration mechanisms for the case of distributed (i.e., on-path) ones. * When distributed advertisements are in place, there are no means defined for reverting planned changes other than reconfiguring and launch new advertisements. 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 internal information beyond the topological changes. Secure ways of accessing to that information can be needed to allow such use cases. 7. 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. Contreras Expires 4 September 2025 [Page 10] Internet-Draft ALTO for TVR March 2025 8. Open issues During the adoption process of this document a number of issues were raised, being here listed as open issues. Next versions of the document will address them. * Issue 1 (raised by Joel Halpern). Make the draft not ALTO- specific. The comment was: "Would it be possible to tighten up the draft to focus on just the applicaiblity to TVR, and not the many othere things ALTO can do?". * Issue 2 (raised by Peng Liu). Clarification of on-path / off- path. The comment was: "There are the words of 'on-path'and 'off- path' but without a clear description at the suitable place, so a brief explanation(e.g at the introduction) will help". * Issue 3 (raised by Jie Dong). Clarification of the TVR information exposed . The comment was: "... clarify that the TVR information exposed via ALTO is about the changes of the connections between PIDs and the associated cost, which is some aggregated network information suitable for some applicationa, while it may be different from the TVR information of the underlay network". * Issue 4 (raised by Jie Dong). Applicability of ALTO-based TVR information. The comment was: "... give some analysis about in which scenarios (or for which applications) the ALTO base TVR information exposure would be applicable". 9. 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, . [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, . [I-D.ietf-tvr-schedule-yang] Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M. Blanchet, "YANG Data Model for Scheduled Attributes", Work Contreras Expires 4 September 2025 [Page 11] Internet-Draft ALTO for TVR March 2025 in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang- 03, 20 October 2024, . [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-10, 27 February 2025, . [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, . [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. [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, . [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, . [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, . Contreras Expires 4 September 2025 [Page 12] Internet-Draft ALTO for TVR March 2025 [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, . [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, . 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. Comparing such architecture with the one depicted in Figure 1, the following mapping is possible, as represented in Figure 2. Contreras Expires 4 September 2025 [Page 13] Internet-Draft ALTO for TVR March 2025 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). 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). Contreras Expires 4 September 2025 [Page 14] Internet-Draft ALTO for TVR March 2025 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 4 September 2025 [Page 15]