Skip to main content

Interconnection Intents
draft-contreras-nmrg-interconnection-intents-04

Document Type Active Internet-Draft (individual)
Authors Luis M. Contreras , Paolo Lucente
Last updated 2024-03-04
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-contreras-nmrg-interconnection-intents-04
NMRG                                                       LM. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                P. Lucente
Expires: 5 September 2024                                            NTT
                                                              March 2024

                        Interconnection Intents
            draft-contreras-nmrg-interconnection-intents-04

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 September 2024.

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 & Lucente     Expires 5 September 2024                [Page 1]
Internet-Draft           Interconnection Intents              March 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  . . . . . . . . . . . . . . . . . . . .   5
   3.  Interconnection intent structure  . . . . . . . . . . . . . .   5
     3.1.  Structure of the Intents  . . . . . . . . . . . . . . . .   6
     3.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Example 1.  Conventional IP peering . . . . . . . . .   7
       3.2.2.  Example 2. interconnection of service functions in
               different domains . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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 & Lucente     Expires 5 September 2024                [Page 2]
Internet-Draft           Interconnection Intents              March 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.

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:

   *  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

Contreras & Lucente     Expires 5 September 2024                [Page 3]
Internet-Draft           Interconnection Intents              March 2024

   *  To facilitate multi-domain network function or service charging,
      by advertising (cumulative) costs in the different domains

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

          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   :   coveying 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 & Lucente     Expires 5 September 2024                [Page 4]
Internet-Draft           Interconnection Intents              March 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 commited 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 & Lucente     Expires 5 September 2024                [Page 5]
Internet-Draft           Interconnection Intents              March 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 & Lucente     Expires 5 September 2024                [Page 6]
Internet-Draft           Interconnection Intents              March 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 & Lucente     Expires 5 September 2024                [Page 7]
Internet-Draft           Interconnection Intents              March 2024

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

   *  -  IntentTargetValue: 10 ms

      -  IntentTargetCondition: lower than

Contreras & Lucente     Expires 5 September 2024                [Page 8]
Internet-Draft           Interconnection Intents              March 2024

4.  Security Considerations

   To be done.

5.  IANA Considerations

   This draft does not include any IANA considerations

6.  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-12, 8 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-sf-
              aware-topo-model-12>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-llc-teas-dc-
              aware-topo-model-03>.

   [IFA050]   "ETSI NFV IFA 050. Management and Orchestration; Intent
              Management Service Interface and Information Model
              Specification", <https://portal.etsi.org/eWPM/
              index.html#/schedule?wki_id=69576>.

   [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, <https://www.rfc-editor.org/info/rfc7336>.

   [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, <https://www.rfc-editor.org/info/rfc9315>.

   [TS28312]  "3GPP TS 28.312. Management and orchestration; Intent
              driven management services for mobile networks (Release
              17)", <https://www.3gpp.org/ftp/Specs/
              archive/28_series/28.312/28312-h60.zip>.

Contreras & Lucente     Expires 5 September 2024                [Page 9]
Internet-Draft           Interconnection Intents              March 2024

   [ZSM011]   "ETSI ZSM 011. Zero-touch network and Service Management
              (ZSM); Intent-driven autonomous networks; Generic
              aspects", <https://www.etsi.org/deliver/etsi_gr/
              ZSM/001_099/011/01.01.01_60/gr_ZSM011v010101p.pdf>.

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/

   Paolo Lucente
   NTT
   Siriusdreef 70-72
   2132 Hoofddorp, WT
   Netherlands
   Email: paolo@ntt.net

Contreras & Lucente     Expires 5 September 2024               [Page 10]