TVR L. M. Contreras Internet-Draft Telefonica Intended status: Informational 10 July 2023 Expires: 11 January 2024 Using ALTO for exposing Time-Variant Routing information draft-contreras-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 mmechanism, on the exposure of such predicted changes to both internal and external applications then anticipating the occurence 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 11 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras Expires 11 January 2024 [Page 1] Internet-Draft ALTO for TVR July 2023 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 . . . 4 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 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security and operational considerations . . . . . . . . . . . 6 6. Informative References . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 [I-D.ietf-tvr-use-cases]. Those predictable changes can be scheduled 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]. 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 such changes in advance in a way that applications (both internal and external) can become aware of those routing variations along time. Contreras Expires 11 January 2024 [Page 2] Internet-Draft ALTO for TVR July 2023 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 for 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 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 activted in the network by the Contreras Expires 11 January 2024 [Page 3] Internet-Draft ALTO for TVR July 2023 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 by a single node can motivate a cascade of some other scheduled changes in different nodes, thus presenting potential stability issues that should be addressed with care. Anyway, in certain environments 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 [I-D.ietf-alto-performance-metrics]. 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]. 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. Contreras Expires 11 January 2024 [Page 4] Internet-Draft ALTO for TVR July 2023 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 teh 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.qu-tvr-schedule-yang]. A model like that could serve the same purpose 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 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. Contreras Expires 11 January 2024 [Page 5] Internet-Draft ALTO for TVR July 2023 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, as suggested in [I-D.taylor-tvr-prb-stmt]. 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]. 4. Discussion Several topics require further discussion with regards the usage of ALTO for TVR. * ALTO enables a way of exposing Time-Variant Routing information to applications. It is necessary to assess if the exposed information reflects the set of actions that can be scheduled in TVR according to [I-D.taylor-tvr-prb-stmt]. * ALTO cost calendar defines a number of time-related attributes. It is necessary to analyze if such attributes are sufficient for expressing the time variance nature of the routing changes in TVR. * The expectation in [I-D.taylor-tvr-prb-stmt] is to extend existing routing protocols to convey TVR information. It is necessary to define how ALTO can participate of the routing information processing and analyzing the new TVR-related information included in the routing protocols. * The data model (or models) that could be defined in TVR could be leveraged by ALTO, so that can be aligned in terms of the time- variant routing information to be exposed to applications. It is needed an analysis of potential improvements to calendared routing-related information in ALTO cost calendar. These topics can motivate further work in TVR and/or ALTO WGs. 5. Security and operational considerations Same security and operational considerations as described in [RFC8896] apply also in this document. 6. Informative References [I-D.contreras-alto-ietf-nef] Contreras, L. M., "Considering ALTO as IETF Network Exposure Function", Work in Progress, Internet-Draft, Contreras Expires 11 January 2024 [Page 6] Internet-Draft ALTO for TVR July 2023 draft-contreras-alto-ietf-nef-01, 11 July 2022, . [I-D.ietf-alto-performance-metrics] Wu, Q., Yang, Y. R., Lee, Y., Dhody, D., Randriamasy, S., and L. M. Contreras, "ALTO Performance Cost Metrics", Work in Progress, Internet-Draft, draft-ietf-alto-performance- metrics-28, 21 March 2022, . [I-D.ietf-tvr-use-cases] Birrane, E. J., Kuhn, N., and Y. Qu, "TVR (Time-Variant Routing) Use Cases", Work in Progress, Internet-Draft, draft-ietf-tvr-use-cases-01, 3 July 2023, . [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, "Digital Twin Network: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft-irtf-nmrg-network-digital- twin-arch-03, 27 April 2023, . [I-D.qu-tvr-schedule-yang] Qu, Y., Lindem, A., and M. Blanchet, "YANG Model for Scheduled Attributes", Work in Progress, Internet-Draft, draft-qu-tvr-schedule-yang-00, 7 July 2023, . [I-D.taylor-tvr-prb-stmt] Taylor, R., "Time Variant Routing Problem Statement", Work in Progress, Internet-Draft, draft-taylor-tvr-prb-stmt-00, 24 October 2022, . [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, . Contreras Expires 11 January 2024 [Page 7] Internet-Draft ALTO for TVR July 2023 [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, . 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 11 January 2024 [Page 8]