[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
Network Working Group                                         S. Barguil
Internet-Draft                                            L.M. Contreras
Intended status: Informational                                  V. Lopez
Expires: 26 August 2021                              O. Gonzalez de Dios
                                                              Telefonica
                                                        22 February 2021


   Instantiation of IETF Network Slices in service providers networks
             draft-barguil-teas-network-slices-instantation-00

Abstract

   The IETF has produced several YANG data models to support the
   Software-Defined Networking and Network Slice Architecture.  This
   document describes the relationship between the abstract (generic, or
   base) Service Models utilized for the Network Slices requests and the
   Network Models (e.g.  L3NM, L2NM).  This document describes the
   communication between the Network Slice Controller and a network
   controller for IETF network slice creation.

   The YANG service models available for network slicing provide a
   customer-oriented view of the network.  Thus, once the Network Slice
   controller (NSC)receives a request, it needs to expand it to
   accomplish the specific parameters expected by the network
   controller.  The network models are analyzed in terms of how they can
   satisfy the IETF Network Slice requirements.  Identified gaps on
   existing models are reported.

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 26 August 2021.






Barguil, et al.          Expires 26 August 2021                 [Page 1]


Internet-Draft   Network models for IETF Network Slices    February 2021


Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Reference architecture  . . . . . . . . . . . . . . . . . . .   3
   3.  IETF Network Slice: requirements and data models  . . . . . .   6
   4.  Yang Models for Network Controllers . . . . . . . . . . . . .   7
     4.1.  LxVPN Network Models  . . . . . . . . . . . . . . . . . .   7
     4.2.  Traffic Engineering Models  . . . . . . . . . . . . . . .   8
     4.3.  Traffic Engineering Service Mapping . . . . . . . . . . .   8
   5.  Compliance of Network Controller models with IETF Network slice
           requirements. . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Availability  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Downlink throughput / Uplink throughput.  . . . . . . . .   9
   6.  Interactions  . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Slice requested to Hierarchical Network Controller  . . .   9
     6.2.  Slice requested to Network Slice Controller . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  12
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The IETF has produced several YANG data models to support the
   Software-Defined Networking and Network Slice Architecture.  This
   document describes the relationship between the abstract (generic, or
   base) Service Models utilized for the Network Slices requests and the
   Network Models (e.g.  L3NM, L2NM, TE, etc).  This document describes
   the communication between the Network Slice Controller and a network
   controller for IETF network slice creation.





Barguil, et al.          Expires 26 August 2021                 [Page 2]


Internet-Draft   Network models for IETF Network Slices    February 2021


   The YANG service models available for network slicing provide a
   customer-oriented view of the network.  Thus, once the Network Slice
   controller (NSC)receives a request, it needs to expand it to
   accomplish the specific parameters expected by the network
   controller.  The network models are analyzed in terms of how they can
   satisfy the IETF Network Slice requirements.  Identified gaps on
   existing models are reported.

   Editor's Note: the terminology in this draft will be aligned with the
   final terminology selected for describing the notion of IETF Network
   Slice when applied to IETF technologies, which is currently under
   discussion.  By now same terminology as used in
   [I-D.ietf-teas-ietf-network-slice-definition] and
   [I-D.nsdt-teas-ns-framework] is primarily used here.  Consensus to
   use "IETF Network Slice" term has been reached.

1.1.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

2.  Reference architecture

   Several architectural definitions have arisen on the IETF to support
   SDN and network slicing deployments.  The architectural proposal
   defined in [I-D.ietf-teas-ietf-network-slice-definition] includes a
   three-level hierarchy and expresses how each level relates with the
   ACTN architecture framework.

   Figure 1 defines a sample architecture using those concepts.  It
   starts from a top consumer or high-level operating system.  Next, the
   network Slice Controller function is part of the Hierarchical network
   controller (e.g., as the MDSC in the ACTN context [RFC8453]) as a
   modular function.  At the bottom, two network controllers, each one
   can handle multiple or single underlay technologies.















Barguil, et al.          Expires 26 August 2021                 [Page 3]


Internet-Draft   Network models for IETF Network Slices    February 2021


                  +------------------------------+
                  | High-level operation system. |
                  +--------------+---------------+
                                 |Slice Request
                                 |
             +-------------------v------------------+
             |                                      |
             |    Hierarchical Network              |
             |    Controller/Orchestrator           |
             |                                      |
             |   +------------------------------+   |
             |   |   Network Slice Controller   |   |
             |   +------------------------------+   |
             |                                      |
             +-------------------+------------------+
                                 |
                                 |
                  +--------------+---------------+
                  |                              |
                  v                              v
    +-------------+----------+     +-------------+----------+
    |   Network Controller   |     |   Network Controller   |
    +-------------+----------+     +-------------+----------+
                  |                              |
                  |                              |
                  v                              v
           Network Elements                Network Elements

   Figure 1 Network Slice Controller as a module of the Hierarchical SDN
   controller.

   In other implementations, the NSC can be a stand-alone element and
   directly interact with the network controller, as depicted in
   Figure 2.  In this scenario, the services request follows a data-
   enrichment path, where each entity adds more information to the
   service request.  This document describes how the available service
   models and network models interact to deliver the network slices in a
   service provider environment.













Barguil, et al.          Expires 26 August 2021                 [Page 4]


Internet-Draft   Network models for IETF Network Slices    February 2021


   +------------------------------+
   | High-level operation system  |
   +--------------+---------------+
                  |Slice Request
                  |
    +-------------v----------------+
    |   Network Slice Controller   |
    +-------------+----------------+
                  |
                  |
                  |
    +-------------v----------------+
    |       Network Controller     |
    +-------------+----------------+
                  |
                  |
                  v
          Network Elements

   Figure 2 Network Slice Controller as a stand-alone entity.

   As another implementation possibility, the Network Slice Controller
   can be integrated with the Network controller and directly realize
   the network slice using device data models to configure the network
   devices.  The sample architecture is depicted in Figure 4.

                  +
                  |Slice/VPN Request
                  |
    +-------------v----------------+
    |      Network Controller      |
    |                              |
    |+----------------------------+|
    ||   Network Slice Controller ||
    |+----------------------------+|
    |                              |
    +-------------+----------------+
                  |
                  |
                  v
          Network Elements

   Figure 3 Network Slice Controller as a module of the Network
   controller.







Barguil, et al.          Expires 26 August 2021                 [Page 5]


Internet-Draft   Network models for IETF Network Slices    February 2021


3.  IETF Network Slice: requirements and data models

   The main set of requirements for the IETF Slice, based on the high-
   level slice requirements from multiple organizations and use cases,
   are compiled in [I-D.contreras-teas-slice-nbi] and reproduced bellow
   for one of the slice use cases reported as example:

   +-----------------------------------------------+
   |  Network Slice Requeriments for 5G service    |
   +-----------------------------------------------+
   | Availability                                  |
   | Deterministic communication                   |
   | Downlink throughput per network slice         |
   | Energy efficiency                             |
   | Group communication support                   |
   | Isolation level                               |
   | Maximum supported packet size                 |
   | Mission critical support                      |
   | Performance monitoring                        |
   | Slice quality of service parameters           |
   | Support for non-IP traffic                    |
   | Uplink throughput per network slice           |
   | User data access (i.e., tunneling mechanisms) |
   +-----------------------------------------------+

   TODO#1: Summarize the requirements based on the different slice use
   cases described in [I-D.contreras-teas-slice-nbi].

   To accomplish those requirements, a set of YANG data models have been
   proposed.  Those Yang models , summarized in table xx, could be used
   by an IETF Network Slice Controller to manage CRUD operations on the
   IETF Network Slice.  That is, these models aim capturing the
   requirements from the consumer of the slice point of view and avoid
   entering into the detail of how the slice is actually created.

   *  [draft-wd-teas-ietf-network-slice-nbi-yang-01]: A Yang Data Model
      for IETF Network Slice NBI.

   *  [draft-liu-teas-transport-network-slice-yang-00]: Transport
      Network Slice YANG Data Model.











Barguil, et al.          Expires 26 August 2021                 [Page 6]


Internet-Draft   Network models for IETF Network Slices    February 2021


4.  Yang Models for Network Controllers

   A network controller, understood as the entity responsible for
   managing a particular network domain, can expose a northbound
   interface based on YANG models.  That is, those YANG models will
   define datastores that apply for a whole network domain and will
   manage network-level concepts.  The types of network models that are
   of interest for the instantiation of IETF Network slices are:

   *  LxVPN Network models:

      -  These models describe a VPN service from the network point of
         view.

   *  Traffic Engineering models:

      -  These models allow to manipulate Traffic Engineering tunnels
         within the network segment.  Technology-specific extensions
         allow to work with a desired technology (e.g.  MPLS RSVP-TE
         tunnels, Segment Routing paths, OTN tunnels, etc.)

   *  TE Service Mapping extensions:

      -  These extensions allow to specify for LxVPN the details of an
         underlay based on TE.

   *  ACLs and routing policies models:

      -  Even though ACLs and routing policies are device models, it's
         exposure in the NBI of a domain controller allows to provide an
         additional granularity that the network domain controller is
         not able to infer on its own.

4.1.  LxVPN Network Models

   The framework defined in [RFC8969] compiles a set of YANG data models
   for automating network services.  The data models can be used during
   the service and network management life cycle (e.g., service
   instantiation, service provisioning, service optimization, service
   monitoring, service diagnosing, and service assurance).  The so
   called Network models could be reused for the realization of Network
   slice requests.

   The following models are examples of Network models that describe
   services.

   *  [I-D.ietf-opsawg-l3sm-l3nm]: A Layer 3 VPN Network YANG Model




Barguil, et al.          Expires 26 August 2021                 [Page 7]


Internet-Draft   Network models for IETF Network Slices    February 2021


   *  [I-D.ietf-opsawg-l2nm]: A Layer 2 VPN Network YANG Model

4.2.  Traffic Engineering Models

   TEAS has defined a collection of models to allow the management of
   Traffic Engineering tunnels.

   *  [I-D.ietf-teas-yang-te]: A YANG Data Model for Traffic Engineering
      Tunnels, Label Switched Paths and Interfaces.  The model allows to
      instantiate paths in a TE enabled network.  Note that technology
      augmented models are require to particular per-technology
      instantiations.

4.3.  Traffic Engineering Service Mapping

   The IETF has defined a YANG model to set up the procedure to map VPN
   service/network models to the TE models.  This model, known as
   service mapping, allows the network controller to assign/retrieve
   transport resources allocated to specific services.  At the moment
   there is just one service mapping model
   [I-D.ietf-teas-te-service-mapping-yang].  The "Traffic Engineering
   (TE) and Service Mapping Yang Model" augments the VPN service and
   network models.

5.  Compliance of Network Controller models with IETF Network slice
    requirements.

   Section 3 presented the requirements of the IETF Network slice.  In
   this subsection it is analyzed how available YANG models that can be
   used by a Network Controller can satisfy those requirements and
   identify gaps.

5.1.  Availability

   As per [draft-ietf-teas-te-service-mapping-yang-05], Availability is
   a probabilistic measure of the length of time that a VPN/VN instance
   functions without a network failure.  As per RFC 8330, The parameter
   "availability", as described in [G.827], [F.1703], and [P.530], is
   often used to describe the link capacity.  The availability is a time
   scale, representing a proportion of the operating time that the
   requested bandwidth is ensured".

   The calculation of the availability is not trivial and would need to
   be clearly scoped to avoid misunderstandings.







Barguil, et al.          Expires 26 August 2021                 [Page 8]


Internet-Draft   Network models for IETF Network Slices    February 2021


   The set of Yang models proposed today allow to request tunnels/paths
   with different resiliency requirements in terms of protection and
   restoration.  However, none of them include the possibility of
   requesting a specific availability (e.g. 99.9999%).

5.2.  Downlink throughput / Uplink throughput.

   The LxVPN Models allow to specify the bandwdidth at the interface
   level between the slice and the customer.  In addition, the TE models
   allow to force a give bandwidth in the connection between Provider
   Edges.

6.  Interactions

6.1.  Slice requested to Hierarchical Network Controller

   When the Network Slice Controller is a Hierarchical SDN controller
   module, the NSC's and the Hierarchical Network Controller should
   share the same internal data and the same NBI.  Thus, to process the
   customer, view the H-SDN module must be able to:

   *  _Map_: The customer request received using the [draft-wd-teas-
      ietf-network-slice-nbi-yang-01] must be processed by the NCS.  The
      mapping process takes the network-slice SLAs selected by the
      customer to available Routing Policies and Forwarding policies.

   *  _Realize_: Create necessary network requests.  The slice's
      realization can be translated into one or several LXNM Network
      requests, depending on the number of underlay controllers.  Thus,
      the NCS must have a complete view of the network to map the orders
      and distribute them across domains.  The realization should
      include the expansion/selection of Forwarding Policies, Routing
      Policies, VPN policies, and Underlay transport preference.

   To maintain the data coherence between the control layers, the
   "network-slice-id" used of the [draft-wd-teas-ietf-network-slice-nbi-
   yang-01] must be directly mapped to the `transport-instance-id at the
   VPN-Node level.













Barguil, et al.          Expires 26 August 2021                 [Page 9]


Internet-Draft   Network models for IETF Network Slices    February 2021


                                 +
                                 |
                                 | Slice Request:
                     draft-wd-teas-ietf-network-slice-nbi-yang-01
                                 | * network-slice-id
                                 |
             +-------------------v------------------+
             |                                      |
             |    Hierarchical Network              |
             |    Controller/Orchestrator           |
             |                                      |
             |   +------------------------------+   |
             |   |   Network Slice Controller   |   |
             |   +------------------------------+   |
             |                                      |
             +-------------------+------------------+
         Slice Realizer: LXNM    |
           VPN-id                |
   * transport-instance-id
                                 |
                  +--------------+---------------+
                  |                              |
                  v                              v
    +-------------+----------+     +-------------+----------+
    |   Network Controller   |     |   Network Controller   |
    +-------------+----------+     +-------------+----------+
                  |                              |
                  |                              |
                  v                              v
           Network Elements                Network Elements

   Figure 4 Workflow for the slice request in an integrated
   architecture.

6.2.  Slice requested to Network Slice Controller

   When the Network Slice Controller is a stand-alone controller module,
   the NSC's should perform the same two tasks described before:

   *  _Map_: Process the customer request.  The customer request can be
      sent using the [draft-liu-teas-transport-network-slice-yang-01].
      This draft allows the topology mapping of the Slice request.

   *  _Realize_: Create necessary network requests.  The slice's
      realization will be translated into one LXNM Network request.  As
      the NCS has a topological view of the network, the realization can
      include the customer's traffic engineering transport preferences
      and policies.



Barguil, et al.          Expires 26 August 2021                [Page 10]


Internet-Draft   Network models for IETF Network Slices    February 2021


                  +
                  |Slice Request
   draft-liu-teas-transport-network-slice-yang-01
   network-id
                  |
    +-------------v----------------+
    |   Network Slice Controller   |
    +-------------+----------------+
                  |
   Slice Realizer: LXNM
     VPN-id       |
     * Underlay-transport
     * transport-instance-id
                  |
    +-------------v----------------+
    |       Network Controller     |
    +-------------+----------------+
                  |
                  |
                  v
          Network Elements

   Figure 5 Workflow for the slice request in an stand-alone
   architecture.

   TODO#2: Include description for the scenario in Figure 3.

7.  Security Considerations

   There are two main aspects to consider.  On the one hand, the IETF
   Network Slice has a set of security related requirements, such as
   hard isolation of the slice, or encryption of the communications
   through the slice.  All those requirements need to be analyzed in
   detailed and cleary mapped to the Network Controller and device
   interfaces.  On the other hand, the communication between the IETF
   network slicer and the network controller (or controllers or
   hierarchy of controllers) need to follow the same security
   considerations as with the network models.  The network YANG modules
   defines schemas for data that is designed to be accessed via network
   management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
   The lowest NETCONF layer is the secure transport layer, and the
   mandatory-to-implement secure transport is Secure Shell (SSH)
   [RFC6242].  The lowest RESTCONF layer is HTTPS, and the mandatory-to-
   implement secure transport is TLS [RFC8466].  The Network
   Configuration Access Control Model (NACM) [RFC8341] provides the
   means to restrict access for particular NETCONF or RESTCONF users to
   a preconfigured subset of all available NETCONF or RESTCONF protocol
   operations and content.



Barguil, et al.          Expires 26 August 2021                [Page 11]


Internet-Draft   Network models for IETF Network Slices    February 2021


   The following summarizes the foreseen risks of using the Network
   Models to instantiate IETF network Slices: - Malicious clients
   attempting to delete or modify VPN services that implements an IETF
   network slice.  The malicious client could manipulate security
   related aspects of the network configuration that impact the
   requirements of the slice, failing to satisfy the customer
   requirement. - Unauthorized clients attempting to create/modify/
   delete a VPN hat implements an IETF network slice service.
   - Unauthorized clients attempting to read VPN services related
   information hat implements an IETF network slice - Malicious clients
   attempting to leak traffic of the slice.

8.  IANA Considerations

   This document is informational and does not require IANA allocations.

9.  Conclusions

   A wide variety of yang models are currently under definition in IETF
   that can be used by Network Controllers to instantiate IETF network
   slices.  Some of the IETF slice requirements can be satisfied by
   multiple means, as there are multiple choices avaialable.  However,
   other requirements are still not covered by the existing models.  A
   more detailed definition of those uncovered requirements would be
   needed.  Finally a consensus on the set of models to be exposed by
   Network Controllers would facilitate the deployment of IETF network
   slices.

10.  Normative References

   [I-D.contreras-teas-slice-nbi]
              Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF
              Network Slice use cases and attributes for Northbound
              Interface of controller", Work in Progress, Internet-
              Draft, draft-contreras-teas-slice-nbi-03, 30 October 2020,
              <https://tools.ietf.org/html/draft-contreras-teas-slice-
              nbi-03>.

   [I-D.ietf-opsawg-l2nm]
              barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil,
              L., and J. Ma, "A Layer 2 VPN Network YANG Model", Work in
              Progress, Internet-Draft, draft-ietf-opsawg-l2nm-01, 2
              November 2020,
              <https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01>.

   [I-D.ietf-opsawg-l3sm-l3nm]
              barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
              Aguado, "A Layer 3 VPN Network YANG Model", Work in



Barguil, et al.          Expires 26 August 2021                [Page 12]


Internet-Draft   Network models for IETF Network Slices    February 2021


              Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05,
              16 October 2020, <https://tools.ietf.org/html/draft-ietf-
              opsawg-l3sm-l3nm-05>.

   [I-D.ietf-teas-ietf-network-slice-definition]
              Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
              Tantsura, "Definition of IETF Network Slices", Work in
              Progress, Internet-Draft, draft-ietf-teas-ietf-network-
              slice-definition-00, 25 January 2021,
              <https://tools.ietf.org/html/draft-ietf-teas-ietf-network-
              slice-definition-00>.

   [I-D.ietf-teas-te-service-mapping-yang]
              Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D.,
              and J. Tantsura, "Traffic Engineering (TE) and Service
              Mapping Yang Model", Work in Progress, Internet-Draft,
              draft-ietf-teas-te-service-mapping-yang-05, 2 November
              2020, <https://tools.ietf.org/html/draft-ietf-teas-te-
              service-mapping-yang-05>.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
              "A YANG Data Model for Traffic Engineering Tunnels, Label
              Switched Paths and Interfaces", Work in Progress,
              Internet-Draft, draft-ietf-teas-yang-te-25, 27 July 2020,
              <https://tools.ietf.org/html/draft-ietf-teas-yang-te-25>.

   [I-D.nsdt-teas-ns-framework]
              Gray, E. and J. Drake, "Framework for Transport Network
              Slices", Work in Progress, Internet-Draft, draft-nsdt-
              teas-ns-framework-04, 13 July 2020,
              <https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-
              04>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.




Barguil, et al.          Expires 26 August 2021                [Page 13]


Internet-Draft   Network models for IETF Network Slices    February 2021


   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

   [RFC8466]  Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
              Data Model for Layer 2 Virtual Private Network (L2VPN)
              Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
              2018, <https://www.rfc-editor.org/info/rfc8466>.

   [RFC8969]  Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
              L. Geng, "A Framework for Automating Service and Network
              Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
              January 2021, <https://www.rfc-editor.org/info/rfc8969>.

Authors' Addresses

   Samier Barguil
   Telefonica
   Distrito T
   Madrid

   Email: samier.barguilgiraldo.ext@telefonica.com


   Luis Miguel Contreras
   Telefonica
   Distrito T
   Madrid

   Email: luismiguel.contrerasmurillo@telefonica.com


   Victor Lopez
   Telefonica
   Distrito T
   Madrid

   Email: victor.lopezalvarez@telefonica.com



Barguil, et al.          Expires 26 August 2021                [Page 14]


Internet-Draft   Network models for IETF Network Slices    February 2021


   Oscar Gonzalez de Dios
   Telefonica
   Distrito T
   Madrid

   Email: oscar.gonzalezdedios@telefonica.com













































Barguil, et al.          Expires 26 August 2021                [Page 15]