idnits 2.17.1 draft-contreras-nmrg-interconnection-intents-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2022) is 827 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-08 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-06 == Outdated reference: A later version (-03) exists of draft-llc-teas-dc-aware-topo-model-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NMRG LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational P. Lucente 5 Expires: July 24, 2022 NTT 6 January 20, 2022 8 Interconnection Intents 9 draft-contreras-nmrg-interconnection-intents-02 11 Abstract 13 This memo introduces the use case of the usage of intents for 14 expressing advance interconnection features, further than traditional 15 IP peering. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 24, 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Evolution of Network interconnection . . . . . . . . . . . . 3 53 2.1. Potential interconnection intent types . . . . . . . . . 3 54 2.2. Interconnection intent lifecycle . . . . . . . . . . . . 4 55 2.3. Protocol aspects . . . . . . . . . . . . . . . . . . . . 4 56 3. Interconnection intent structure . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The success of Internet-based services has been built on top of the 66 global reachability of content accessed by the end-users, which is 67 facilitated by the interconnection of individual networks owned by 68 distinct service providers constituting independent administrative 69 domains. 71 Such interconnection services have been initially based simply on 72 delivery of IP traffic between the interconnected parties leveraging 73 on BGP. This peer model enables full connectivity. However, the 74 traditional interconnection model shows some limitations when 75 additional information to that related to routing is needed. 77 New network capabilities based on programmability and virtualization 78 are producing service situations where a connectivity-only approach 79 is not sufficient. The increasing availability of computing 80 capabilities internal to the networks, or attached to them, enable 81 new scenarios where those capabilities can be consumed through the 82 advertisement or exposure of these execution environments (i.e., in 83 terms of compute, storage and associated networking resources). Such 84 information from an interconnected provider can be obtained from e.g. 85 [I-D.llc-teas-dc-aware-topo-model]. 87 In addition or complementary to that, even services or network 88 functions could be advertised in order to make them available for 89 interconnection. For example, as service we could consider the 90 advertisement of CDN capabilities as in CDNi approach [RFC7336], 91 while as network function we could consider functions like firewall, 92 CGNAT, etc, present in the network 93 [I-D.ietf-teas-sf-aware-topo-model]. 95 All these scenarios present clear evolutions of the interconnection 96 model which can not be simply expressed through existing mechanisms, 97 or at least, cannot be expressed in a simple (and comprehensive) way 98 with such existing mechanisms. Here is where an advanced 99 interconnection intent can assist on declaring the goal of the 100 interconnection transcending pure IP traffic exchange and including 101 more advance capabilities as the ones mentioned before. 103 2. Evolution of Network interconnection 105 It becomes clear the trend to increasingly rely on multi-domain 106 scenarios for the provision of services. For instance, the access 107 today to an on-demand OTT video on Internet implies the interaction 108 of more than one single administrative domain. Thus, end-to-end 109 service delivery over multiple providers or domains is becoming the 110 norm. 112 Complex network services leveraging on virtualization solutions and 113 different infrastructure environments pertaining to distinct 114 administrative domains (i.e., operated and managed by distinct 115 providers) can be easily foreseen. 117 It is then necessary to explore mechanisms for interconnecting that 118 multiple domain environments in a common, portable way independently 119 of the owner of such infrastructure. 121 2.1. Potential interconnection intent types 123 The interconnection intent should provide enough abstractions to 124 express a variety of interconnection options. 126 The purpose of the interconnection intent can be multiple: 128 o to enable multi-domain network service programming, by soliciting 129 interconnection of service / network functions in different 130 domains 132 o to enable multi-domain deployment of virtualized network 133 functions, by advertising the availability of compute and storage 134 resources in different domains 136 o to facilitate multi-domain network function or service charging, 137 by advertising (cumulative) costs in the different domains 139 o to enable traffic interchange, ie. IP as in traditional peering 140 or optical 142 o to put in place the right collection of policies to implement and 143 operate the interconnection 145 o to facilitate whatever combination of all of them 147 2.2. Interconnection intent lifecycle 149 [I-D.irtf-nmrg-ibn-concepts-definitions] defines an intent lifecycle 150 composed of two phases, namely fulfillment and assurance. Figure 1 151 captures the intent procedure for the fulfillment phase (assurance 152 phase will be detailed in future versions of this draft). 154 User Space : Translation / IBS : Network Ops 155 : Space : Space 156 : : 157 +----------+ : +----------+ +-----------+ : +-----------+ 158 Fulfill |recognize/|---> |translate/|-->| learn/ |-->| configure/| 159 |generate | | | | plan/ | | provision | 160 |intent |<--- | refine | | render | : | | 161 +----------+ : +----------+ +-----------+ : +-----------+ 162 : : 163 ......................................................................... 165 Provider A : Provider B 166 ---------- : ---------- 167 : 168 - Select interconn. : - Mapping of intent types to : - Establishment of 169 intent type : protocols / APIs for : protocol sessions 170 - Specify targeted : coveying targeted resources : or API requests 171 resources (i.e., : - Parametrization of that : for configure or 172 routes, compute : protocols / APIs, e.g. : provisioning 173 quotes, service : leveraging on data models : targeted resources 174 functions, etc.) : : 175 : : 177 Figure 1: Fulfillment phase of the Interconnection Intent 179 2.3. Protocol aspects 181 Ultimately the ideas and notions elaborated in this document will 182 need to find room in a framework made of one or multiple protocols 183 (ie. BGP, LISP, etc.) and/or API definitions. While the exact 184 definition of such framework is left as future work, in this document 185 we intend to perform some seminal work in this sense (ie. identify 186 existing protocols that could fit, determine gaps of such protocols, 187 etc.). 189 3. Interconnection intent structure 191 To be done. 193 4. Security Considerations 195 To be done. 197 5. IANA Considerations 199 This draft does not include any IANA considerations 201 6. References 203 [I-D.ietf-teas-sf-aware-topo-model] 204 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, L. 205 M., Ceccarelli, D., Tantsura, J., and D. Shytyi, "SF Aware 206 TE Topology YANG Model", draft-ietf-teas-sf-aware-topo- 207 model-08 (work in progress), July 2021. 209 [I-D.irtf-nmrg-ibn-concepts-definitions] 210 Clemm, A., Ciavaglia, L., Granville, L. Z., and J. 211 Tantsura, "Intent-Based Networking - Concepts and 212 Definitions", draft-irtf-nmrg-ibn-concepts-definitions-06 213 (work in progress), December 2021. 215 [I-D.llc-teas-dc-aware-topo-model] 216 Lee, Y., Liu, X., and L. M. Contreras, "DC aware TE 217 topology model", draft-llc-teas-dc-aware-topo-model-01 218 (work in progress), July 2021. 220 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 221 "Framework for Content Distribution Network 222 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 223 August 2014, . 225 Acknowledgments 227 This work has been partly funded by the European Commission through 228 the H2020 project 5GROWTH (Grant Agreement no. 856709). 230 Authors' Addresses 231 Luis M. Contreras 232 Telefonica 233 Ronda de la Comunicacion, s/n 234 Sur-3 building, 3rd floor 235 Madrid 28050 236 Spain 238 Email: luismiguel.contrerasmurillo@telefonica.com 239 URI: http://lmcontreras.com/ 241 Paolo Lucente 242 NTT 243 Siriusdreef 70-72 244 Hoofddorp, WT 2132 245 Netherlands 247 Email: paolo@ntt.net