NMRG LM. Contreras Internet-Draft Telefonica Intended status: Informational P. Lucente Expires: 9 January 2025 NTT T. Velivassaki Synelixis July 2024 Interconnection Intents draft-contreras-nmrg-interconnection-intents-05 Abstract This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. 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 2 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Contreras, et al. Expires 9 January 2025 [Page 1] Internet-Draft Interconnection Intents July 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Evolution of Network interconnection . . . . . . . . . . . . 3 2.1. Potential interconnection intent types . . . . . . . . . 3 2.2. Interconnection intent lifecycle . . . . . . . . . . . . 4 2.3. Protocol aspects . . . . . . . . . . . . . . . . . . . . 6 3. Interconnection intent structure . . . . . . . . . . . . . . 6 3.1. Structure of the Intents . . . . . . . . . . . . . . . . 7 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Example 1. Conventional IP peering . . . . . . . . . 8 3.2.2. Example 2. interconnection of service functions in different domains . . . . . . . . . . . . . . . . . . 9 3.2.3. Example 3. Delivery of composite service functions at the edge and cloud continuum . . . . . . . . . . . . 10 4. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The success of Internet-based services has been built on top of the global reachability of content accessed by the end-users, which is facilitated by the interconnection of individual networks owned by distinct service providers constituting independent administrative domains. Such interconnection services have been initially based simply on delivery of IP traffic between the interconnected parties leveraging on BGP. This peer model enables full connectivity. However, the traditional interconnection model shows some limitations when additional information to that related to routing is needed. New network capabilities based on programmability and virtualization are producing service situations where a connectivity-only approach is not sufficient. The increasing availability of computing capabilities internal to the networks, or attached to them, enable new scenarios where those capabilities can be consumed through the advertisement or exposure of these execution environments (i.e., in terms of compute, storage and associated networking resources). Such information from an interconnected provider can be obtained from e.g. [I-D.llc-teas-dc-aware-topo-model]. Contreras, et al. Expires 9 January 2025 [Page 2] Internet-Draft Interconnection Intents July 2024 In addition or complementary to that, even services or network functions could be advertised in order to make them available for interconnection. For example, as service we could consider the advertisement of CDN capabilities as in CDNi approach [RFC7336], while as network function we could consider functions like firewall, CGNAT, etc, present in the network [I-D.ietf-teas-sf-aware-topo-model]. All these scenarios present clear evolutions of the interconnection model which can not be simply expressed through existing mechanisms, or at least, cannot be expressed in a simple (and comprehensive) way with such existing mechanisms. Here is where an advanced interconnection intent can assist on declaring the goal of the interconnection transcending pure IP traffic exchange and including more advance capabilities as the ones mentioned before. 2. Evolution of Network interconnection It becomes clear the trend to increasingly rely on multi-domain scenarios for the provision of services. For instance, the access today to an on-demand OTT video on Internet implies the interaction of more than one single administrative domain. Thus, end-to-end service delivery over multiple providers or domains is becoming the norm. Complex network services leveraging on virtualization solutions and different infrastructure environments pertaining to distinct administrative domains (i.e., operated and managed by distinct providers) can be easily foreseen. It is then necessary to explore mechanisms for interconnecting that multiple domain environments in a common, portable way independently of the owner of such infrastructure. In addition to that, the evolution of edge and cloud computing has enabled scenarios of seamless service delivery across such diverse resources. Moreover, high availability requirements urge for considering multi-cluster service deployment and delivery for the network functions. 2.1. Potential interconnection intent types The interconnection intent should provide enough abstractions to express a variety of interconnection options. The purpose of the interconnection intent can be multiple: Contreras, et al. Expires 9 January 2025 [Page 3] Internet-Draft Interconnection Intents July 2024 * To enable multi-domain network service programming, by soliciting interconnection of service / network functions in different domains * To enable multi-domain deployment of virtualized network functions, by advertising the availability of compute and storage resources in different domains * To facilitate multi-domain network function or service charging, by advertising (cumulative) costs in the different domains * To enable delivery of service functions in the edge and cloud continuum * To enable traffic interchange, ie. IP as in traditional peering or optical * To put in place the right collection of policies to implement and operate the interconnection * To facilitate whatever combination of all of them 2.2. Interconnection intent lifecycle [RFC9315] defines an intent lifecycle composed of two phases, namely fulfillment and assurance. Figure 1 captures the intent procedure for the fulfillment phase. Contreras, et al. Expires 9 January 2025 [Page 4] Internet-Draft Interconnection Intents July 2024 User Space : Translation / IBS : Network Ops : Space : Space : : +----------+ : +----------+ +-----------+ : +-----------+ Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| |generate | | | | plan/ | | provision | |intent |<--- | refine | | render | : | | +----------+ : +----------+ +-----------+ : +-----------+ : : ......................................................................... Provider A : Provider B ---------- : ---------- : - Select interconn. : - Mapping of intent types to : - Establishment of intent type : protocols / APIs for : protocol sessions - Specify targeted : conveying targeted resources : or API requests resources (i.e., : - Parametrization of that : for configure or routes, compute : protocols / APIs, e.g. : provisioning quotes, service : leveraging on data models : targeted resources functions, etc.) : : : : Figure 1: Fulfillment phase of the Interconnection Intent Similarly, Figure 2 sketches the intent procedure for the assurance phase. Contreras, et al. Expires 9 January 2025 [Page 5] Internet-Draft Interconnection Intents July 2024 : +--------+ : : |validate| : +----------+ : +----^---+ <----| monitor/ | Assure +-------+ : +---------+ +-----+---+ : | observe/ | |report | <---- |abstract |<---| analyze | <----| | +-------+ : +---------+ |aggregate| : +----------+ : +---------+ : ..................................................................... Provider A : Provider B ---------- : ---------- : - Analysis of the : - Checking of monitored data : - Collection of reported metrics : for internal closed loops : telemetry info against the intent : to ensure committed SLOs : related to allocated request : (inner closed loop) : resources (i.e., - Trigger of actions : - Aggregation of data : routes, compute if needed, e.g., : producing an abstracted view: quotes, service new intent (outer : fitted to the intent request: functions, etc.) closed loop) : : Figure 2: Assurance phase of the Interconnection Intent Both Fulfillment and Assurance phases are integral part of the interconnection intent. 2.3. Protocol aspects Ultimately the ideas and notions elaborated in this document will need to find room in a framework made of one or multiple protocols (ie. BGP, LISP, ALTO, etc.) and/or API definitions. While the exact definition of such framework is left as future work, in this document we intend to perform some seminal work in this sense (ie. identify existing protocols that could fit, determine gaps of such protocols, etc.). 3. Interconnection intent structure In order to address the different interconnection intent types described in section 2.1, the structure of the intent should be sufficiently flexible to allow the expression of different targets. Thus, the intent structure could include: * Information of the type of data traffic being subject of the interconnection intent (e.g., IP prefixes involved) among providers. Contreras, et al. Expires 9 January 2025 [Page 6] Internet-Draft Interconnection Intents July 2024 * Service functions expected to be supported by the peer provider. These could be expressed in terms of type of service function and number of instances required. Furthermore, it can be necessary to consider how the service functions are expected to be connected in terms of topology (i.e., service function graph). * Resources expected to be offered by the peer provider. These could be expressed in terms of raw values of number of CPUs, memory and storage size, or bandwidth capacity, or alternatively, in terms of quotas grouping resources in a predefined manner. * Constraints that could apply to whatever of the elements included in the interconnection intent, including traffic steering ones. Aspects such as committed rates, burst size, cumulative traffic, service function affinity, redundancy, traffic engineering (e.g., latency), etc., could be part of such constraints. * Further information that could be necessary for delivering an end- to-end service by means of the intent. 3.1. Structure of the Intents Different Standardization Development Organizations (SDOs) are working on the area of intents. This is the case of ETSI ZSM [ZSM011], ETSI NFV [IFA050], or 3GPP [TS 28312]. The structure of the declarative intent model along those SDOs follows a common design, considering a number of classes (i.e., objects that can be instantiated) and data types (i.e., assigned values) as described next: * Expectation: it refers to the expectation(s) of an intent including the requirements, goals, constraints and context that apply to it. * Target: it refers to the behavioral outcomes resulting from the configurations derived from the intent expectation. A given intent expectation may include various targets. * Condition: it applies to the value of the target. * Context: It describes constraints or conditions applicable to the intent expectation. The same model will be followed in this document for exemplifying possible interconnection intents. Contreras, et al. Expires 9 January 2025 [Page 7] Internet-Draft Interconnection Intents July 2024 Note: Further alignment is yet needed with the referenced models in other SDOs. 3.2. Examples Section 2.1 presented potential interconnection intent types. This section proposes examples of declarative intents for those interconnection cases. Note: further versions will refine and complete the examples. 3.2.1. Example 1. Conventional IP peering Conventional IP peering leverages on BGP for performing interdomain interconnection between two Autonomous Systems (AS). The conventional IP peering intent could consider the following details: * Peer AS number (ASN) and IP address * Peering authentication (e.g., MD5) * Traffic levels (e.g., PIR, CIR, etc) The following intent can serve for the purposes of requesting peering in a declarative manner from peer A (with ASN N and IP address ipA) to peer B (with ASN M and IP address ipB) * IntentExpectation: IP_peering * - IntentTarget: AutonomousSystem - o IntentTargetValue: M o IntentContext: ASorigin = N * - IntentTarget: IP_address - o IntentTargetValue: ipB o IntentContext: IPorigin = ipA * - IntentTarget: CIR - o IntentTargetValue: 1 Gbps * - IntentTarget: Authentication - o IntentTargetValue: MD5 Contreras, et al. Expires 9 January 2025 [Page 8] Internet-Draft Interconnection Intents July 2024 As result of the intent, peering session between providers could be trigger by automated means, such as for instance [I-D.ramseyer-grow-peering-api]. Proper translation of the intent to [I-D.ramseyer-grow-peering-api] is left for further work. 3.2.2. Example 2. interconnection of service functions in different domains Service functions could be deployed in different administrative domains, being of interest to interconnect them for creating a service chain. An interconnection of this kind could consider as relevant information: * Service function in peer domain * Preferred location (i.e., geographical area) * Connection Service Level Objectives (e.g., bandwidth, latency, etc) * Preferred peering point (in terms of existing peering session identified by peer Ip address) The following intent can serve for the purposes of requesting interconnection with a service function SF2 of peer B from service function SF1 from peer A, with the expectation of connecting both service functions observing a bandwidth capacity of up to 1 Gbps during 90% of the time, and a latency lower than 10 ms. * IntentExpectation: SF_interconnect * - IntentTarget: ServiceFunction - o IntentTargetValue: SF2 o IntentContext: SForigin = SF1 * - IntentTarget: Location - o IntentTargetValue: Zone_X * - IntentTarget: SLO_Bandwidth - o IntentTargetValue: 1 Gbps o IntentTargetContext: 90% * IntentTarget: SLO_Latency Contreras, et al. Expires 9 January 2025 [Page 9] Internet-Draft Interconnection Intents July 2024 * - IntentTargetValue: 10 ms - IntentTargetCondition: lower than 3.2.3. Example 3. Delivery of composite service functions at the edge and cloud continuum Service functions may collectively deliver composite functionality in the context of a service chain. In addition, service functions can be delivered at different parts of the network, including the edge of the network. For the delivery of such composite service functions, performance characteristics should be assured coherently for seamless service delivery in the continuum. Therefore, service function delivery at diverse network parts should consider: * The service chain in which the service function belongs to * The node types (e.g. edge, cloud, etc.)) in which the service functions may be executed * Computational Service Level Objectives (e.g., virtual cpu, memory, or storage) * Connection Service Level Objectives (e.g., bandwidth, latency, etc.) The intent for expressing an expectation of interconnection of service function SF1 of peer A to service function SF2 of peer B, potentially delivered in resources across the edge-cloud continuum and which together deliver composite functionality, can be formulated as follows. * IntentExpectation: SF_continuum * - IntentTarget: ServiceFunction - o IntentTargetValue: SF2 o IntentContext: SFcomposite = SF0 * - IntentTarget: NodeType - o IntentContext: EdgeCloud * - IntentTarget: SLO_Vcpu - o IntentTargetValue: 2 Contreras, et al. Expires 9 January 2025 [Page 10] Internet-Draft Interconnection Intents July 2024 o IntentTargetCondition: greater than * - IntentTarget: SLO_Vram - o IntentTargetValue: 4 o IntentTargetCondition: greater than * - IntentTarget: SLO_Bandwidth - o IntentTargetValue: 1 Gbps o IntentTargetContext: 90% * IntentTarget: SLO_Latency * - IntentTargetValue: 10 ms - IntentTargetCondition: lower than A working example is available on NEMO source code [NEMO_API]. 4. Lessons Learned The experimental part of this document is yet a work in progress. However some initial lessons can be derived from it, as follows: * New services imbricate an interplay of cloud and network technologies. Furthermore, such services typically involved more than one provider, and could span multiple administrative domains. Finding proper ways of automating service deployment and operation is a must, and requires the possibility of triggering actions in cloud and network. Intents can play a relevant role there, because their level of abstraction. * Multiple adaptors could be required due to the different technologies underneath, both at cloud and network levels. Different cloud managers (e.g., Kubernetes, Openstack, etc) and network automation capabilities (e.g., SDN controller, Network Slice controller, overlay solutions, etc) could participate of a single service. * Common, abstract intents should be defined and agreed among parties so to enable automation in multi-domain scenarios. This implies common understanding and expectations of the intents, as well as negotiation capabilities and monitoring, for intent assessment in this scenarios where contractual relationships will happen. Contreras, et al. Expires 9 January 2025 [Page 11] Internet-Draft Interconnection Intents July 2024 This section will be further elaborated as long as the experimental work advances. 5. Security Considerations To be done. 6. IANA Considerations This draft does not include any IANA considerations 7. References [I-D.ietf-teas-sf-aware-topo-model] Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, L. M., Ceccarelli, D., Tantsura, J., and D. Shytyi, "SF Aware TE Topology YANG Model", Work in Progress, Internet-Draft, draft-ietf-teas-sf-aware-topo-model-13, 4 July 2024, . [I-D.llc-teas-dc-aware-topo-model] Lee, Y., Liu, X., and L. M. Contreras, "DC aware TE topology model", Work in Progress, Internet-Draft, draft- llc-teas-dc-aware-topo-model-03, 10 July 2023, . [I-D.ramseyer-grow-peering-api] Aguado, C., Griswold, M., Ramseyer, J., Servin, A. L., and T. Strickx, "Peering API", Work in Progress, Internet- Draft, draft-ramseyer-grow-peering-api-05, 30 May 2024, . [IFA050] "ETSI NFV IFA 050. Management and Orchestration; Intent Management Service Interface and Information Model Specification", . [NEMO_API] "NEMO source code; Intent API", . Contreras, et al. Expires 9 January 2025 [Page 12] Internet-Draft Interconnection Intents July 2024 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, . [RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, . [TS28312] "3GPP TS 28.312. Management and orchestration; Intent driven management services for mobile networks (Release 17)", . [ZSM011] "ETSI ZSM 011. Zero-touch network and Service Management (ZSM); Intent-driven autonomous networks; Generic aspects", . Contributors The following people have contributed to this document. Guillermo Sanchez Illan (guillermo.sanchezillan@telefonica.com), Telefonica. Artemios Tomaras (tomaras@synelixis.com), Synelixis. Theodore Zahariadis (zahariad@synelixis.com), Synelixis. Acknowledgments This work has been partially funded by the European Union under Horizon Europe project NEMO (NExt generation Meta Operating system) grant number 101070118. Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n Sur-3 building, 1st floor 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com/ Contreras, et al. Expires 9 January 2025 [Page 13] Internet-Draft Interconnection Intents July 2024 Paolo Lucente NTT Siriusdreef 70-72 2132 Hoofddorp, WT Netherlands Email: paolo@ntt.net Terpsichori Helen Velivassaki Synelixis Farmakidou 10 34100 Chalkida Greece Email: terpsi@synelixis.com Contreras, et al. Expires 9 January 2025 [Page 14]