[Teas] Proposal for text on realising network slices

Adrian Farrel <adrian@olddog.co.uk> Wed, 21 April 2021 20:46 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68123A361C for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 13:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.782
X-Spam-Level:
X-Spam-Status: No, score=0.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=2.7, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30tL6dYA-Q5t for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 13:46:06 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98E533A3619 for <teas@ietf.org>; Wed, 21 Apr 2021 13:46:04 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13LKk2qF026235; Wed, 21 Apr 2021 21:46:02 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EA34B2203A; Wed, 21 Apr 2021 21:46:01 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id D4FC522032; Wed, 21 Apr 2021 21:46:01 +0100 (BST)
Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13LKk0NY008574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Apr 2021 21:46:01 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'TEAS WG'" <teas@ietf.org>
Cc: <adrian@olddog.co.uk>
Date: Wed, 21 Apr 2021 21:45:59 +0100
Organization: Old Dog Consulting
Message-ID: <05a501d736ef$56f046f0$04d0d4d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adc27qdMKWA/DfnbTSu4b3UQUXAOaA==
Content-Language: en-gb
X-Originating-IP: 81.174.197.74
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26106.002
X-TM-AS-Result: No--8.136-10.0-31-10
X-imss-scan-details: No--8.136-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26106.002
X-TMASE-Result: 10--8.135600-10.000000
X-TMASE-MatchedRID: bv5dD/XoaCPd+T+HbpI2c3FPUrVDm6jtd1LU8AXwtKAiXE6jAom+xcOL WoD10UccXw8SDK+AsGnQ2lMrz9wQrm00sCPwNg7wcTwOmq5GKdBxXefgn/TNQ1gLks93sG9tIvL BZn8IAhj//16+gjMcG+kZKjXp7itHDSqYlKHgkv84YnIkEf/g0KUB+KILVUD9K4YqHgCSopXVMM q4+Qor8gXtme8N0/6lcJo61gvBlpUx4g+7LKrJbBVDIsSGCK56VBPjB/Of+FQP5cY6GBn/h3J2g 7BJb0I163QJc34CXasP+9UdxvwghnEcMtD4k81I5dgjTPgwOPRzmB71otxffGquw69QUQrLxqOK d6/jtTbpYppaw3/Yq/lnvszelnK2i2ocXnQGeYYAPmNKDWsW0E7TaZP2WLdUJs1nmlVDLIi6JV/ T/Mrtr/3E6u6XDCcE8n+TRW1yhDOP2t7muadLtDXgRPG8Apuya1wRdX1rZ05TbQ95zRbWVrssAC 2EjddGWkJjSXAB1nCvNkw7wlOrK0t/yRxvHajqJOMhINYq80xiosdBXRsvH/F8GDHRN+Itzplqe 7NBrM2a8/6z4WIQ4XDBwe7UZV+n7ZpdgJkP1WL40JAO63Qrhffjx7YIT/BiRZrOmBLNtw9opS6Z JZnGy4xVKDrvkkrso7BsXTD1U6w8+glRcTaRJreoRc1zsKT5f/TIOqPsDItHNQon9ngWG2PPV+i AXW6bi9/EJtCdXpU0+ernH+QTIgo28QW8mesc54eqweLWaL5lnkeRE0Y2A+tVpQO2kRrXBGNnj9 PMGXI9+VF9zTdE5Ivz3j9UQdFadm10NLkSjkGeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtBK9GKpTmnoryusiSiydMxfJDMj/1FKYVryilg0jmkYwbkBETHwXOIQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nGe0E2waUMW8IfC7LLS-FXEL-GU>
Subject: [Teas] Proposal for text on realising network slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 20:46:10 -0000

All,

I promised a revision of the text around realizing network slicing.
This is based on my earlier suggestion (on the list) about reducing the
ACTN section, and the thread with Daniele about referencing the various
possible solution technologies. 

Here is a suggestion for:
- removing a little text from sections 3 and 5
- making a small change to 5.2
- replacing sections 5.5 and 6 with a new section 6

Comments are encouraged.

I will leave a respectful period of time and then post an update. Once
updated, this text in the draft can still be discussed and modified.

Best,
Adrian

===

3.

OLD
   As an example of requirements that might apply to IETF Network
   Slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3).
NEW
END

---

5.

OLD
   Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example
   architecture that might apply in using the technology described in
   this document.
NEW
END

---

5.2
OLD
   Layered virtual connections are comprehensively discussed in IETF
   documents and are widely supported.  See, for instance, GMPLS-based
   networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and
   [RFC8454]).  The principles and mechanisms associated with layered
   networking are applicable to IETF Network Slices.
NEW
   Layered virtual connections are comprehensively discussed in IETF
   documents and are widely supported.  See, for instance, GMPLS-based
   networks [RFC5212] and [RFC4397], or Abstraction and Control of TE
   Networks (ACTN) [RFC8453] and [RFC8454].  The principles and
   mechanisms associated with layered networking are applicable to IETF
   Network Slices.
END

---

OLD
5.5.  Realizing IETF Network Slice

   Realization of IETF Network Slices is out of scope of this document.
   It is a mapping of the definition of the IETF Network Slice to the
   underlying infrastructure and is necessarily technology-specific and
   achieved by the NSC over the SBI.

   The realization can be achieved in a form of either physical or
   logical connectivity through VPNs (see, for example,
   [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies
   such as Segment Routing, MPLS, etc.  Accordingly, endpoints may be
   realized as physical or logical service or network functions.

5.5.1.  Underlying Technology

   There are a number of different technologies that can be used,
   including physical connections, MPLS, TSN, Flex-E, etc.

   See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for
   example underlying technologies.

   Also, as outlined in "applicability of ACTN to IETF Network Slices"
   below, ACTN ([RFC8453]) offers a framework that is used elsewhere in
   IETF specifications to create virtual network (VN) services similar
   to IETF Network Slices.

   A IETF Network Slice can be realized in a network, using specific
   underlying technology or technologies.  The creation of a new IETF
   Network Slice will be initiated with following three steps:

   o  Step 1: A higher level system requests connections with specific
      characteristics via NBI.

   o  Step 2: This request will be processed by an IETF NSC which
      specifies a mapping between northbound request to any IETF
      Services, Tunnels, and paths models.

   o  Step 3: A series of requests for creation of services, tunnels and
      paths will be sent to the network to realize the trasport slice.

   It is very clear that regardless of how IETF Network Slice is
   realized in the network (i.e., using tunnels of type RSVP or SR), the
   definition of IETF Network Slice does not change at all but rather
   its realization.

6.  Applicability of ACTN to IETF Network Slices

   Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an
   example of similar IETF work.  ACTN defines three controllers to
   support virtual network (VN) services -

   o  Customer Network Controller (CNC),

   o  Multi-Domain Service Coordinator (MDSC) and

   o  Provisioning Network Controller (PNC).

   A CNC is responsible for communicating a customer's VN requirements.

   A MDSC is responsible for multi-domain coordination, virtualization
   (or abstraction), customer mapping/translation and virtual service
   coordination to realize the VN requirement.  Its key role is to
   detach the network/service requirements from the underlying
   technology.

   A PNC oversees the configuration, monitoring and collection of the
   network topology.  The PNC is a underlay technology specific
   controller.

   While the ACTN framework is a generic VN framework that is used for
   various VN service beyond the IETF Network Slice, it is still a
   suitable basis to understand how the various controllers interact to
   realize a IETF Network Slice.

   One possible mapping between the IETF Network Slice, and ACTN,
   definitions is as shown in Figure 4.

                   IETF Network Slice                |   ACTN analogous
                 Terminology / Concepts                  Terminology
                                                     |    and Concepts
          +--------------------------------------+
          |Consumer higher level operation system|   |    +-----+
          | (e.g E2E network slice orchestrator) | =====> | CNC |
          +--------------------------------------+   |    +-----+
                            ^                                ^
                            | NSC NBI                |       | CMI
                            v                                v
          +-------------------------------------+    |    +------+
          | IETF Network Slice Controller (NSC) |  =====> | MDSC |
          +-------------------------------------+    |    +------+
                            ^                                ^
                            | NSC SBI                |       | MPI
                            v                                v
          +-------------------------------------+    |    +-----+
          |        Network Controller(s)        |  =====> | PNC |
          +-------------------------------------+    |    +-----+


          Figure 4: Mapping between IETF Network Slices and ACTN

   The NSC NBI conveys the generic IETF Network Slice requirements.
   These may then be realized using an SBI within the NSC.

   As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC
   Interface (CMI) is used to convey the virtual network service
   requirements along with the service models and the MDSC-PNC Interface
   (MPI) is used to realize the service along network configuration
   models.  [I-D.ietf-teas-te-service-mapping-yang] further describe how
   the VPN services can be mapped to the underlying TE resources.

   The Network Controller is depicted as a single block, analogous to a
   Provisioning Network Controller (PNC - in this example).  In the ACTN
   framework, however, it is also possible that the NC function is
   decomposed into MDSC and PNC - that is, the NC may comprise hierarchy
   as needed to handle the multiple domains and various underlay
   technologies, whereas a PNC in ACTN is intended to be specific to at
   most a single underlay technology and (likely) to individual devices
   (or functional components).

   Note that the details of potential implementations of everything that
   is below the NSC in Section 6 are out of scope in this document -
   hence the specifics of the relationship between NC and PNC, and the
   possibility that the MDSC and PNC may be combined are at most
   academically interesting in this context.  Another way to view this
   is that, in the same way that ACTN might combine MDSC and PNC, the
   NSC might also directly include NC functionality.

   [RFC8453] also describes TE Network Slicing in the context of ACTN as
   a collection of resources that is used to establish a logically
   dedicated virtual network over one or more TE networks.  In case of
   TE enabled underlying network, ACTN VN can be used as a base to
   realize the IETF Network Slicing by coordination among multiple peer
   domains as well as underlay technology domains.

   Section 6 shows only one possible mapping as each ACTN component (or
   interface) in the figure may be a composed differently in other
   mappings, and the exact role of both components and subcomponents
   will not be always an exact analogy between the concepts used in this
   document and those defined in ACTN.

   This is - in part - shown in a previous paragraph in this section
   where it is pointed out that the NC may actually subsume some aspects
   of both the MDSC and PNC.

   Similarly, in part depending on how "customer" is interpreted, CNC
   might merge some aspects of the higher level system and the NSC.  As
   in the NC/PNC case, this way of comparing ACTN to this work is not
   useful as the NSC and NSC NBI are the focus on this document.
NEW
6.  Realizing IETF Network Slice

   Realization of IETF Network Slices is out of scope of this document.
   It is a mapping of the definition of the IETF Network Slice to the
   underlying infrastructure and is necessarily technology-specific and
   achieved by the NSC over the SBI.

   The realization can be achieved in a form of either physical or
   logical connectivity using VPNs, virtual networks (VNs), or a variety
   of tunneling technologies such as Segment Routing, MPLS, etc. 
   Accordingly, endpoints (NSEs) may be realized as physical or logical
   service or network functions.

6.1.  Underlying Technology

   There are a number of different technologies that can be used in the
   underlay, including physical connections, MPLS, time-sensitive 
   networking (TSN), Flex-E, etc.

   An IETF Network Slice can be realized in a network, using specific
   underlying technology or technologies.  The creation of a new IETF
   Network Slice will be initiated with following three steps:

   o  Step 1: A higher level system requests connections with specific
      characteristics via the NBI.

   o  Step 2: This request will be processed by an IETF NSC which
      specifies a mapping between northbound request to any IETF
      Services, Tunnels, and paths models.

   o  Step 3: A series of requests for creation of services, tunnels and
      paths will be sent to the network to realize the transport slice.

   It is very clear that, regardless of how IETF Network Slice is
   realized in the network (i.e., using tunnels of different types), the
   definition of the IETF Network Slice does not change at all.  The 
   only difference is how the slice is realized.  The following sections
   briefly introduce some existing approaches that can be applied to 
   realize IETF Network Slices.

6.2.  Applicability of ACTN to IETF Network Slices

   Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a
   management architecture and toolkit used to create virtual networks
   (VNs) on top of a traffic engineering (TE) underlay network.  The VNs
   can be presented to customers for them to operate as private
   networks.

   In many ways, the function of ACTN is similar to IETF network
   slicing.  Customer requests for connectivity-based overlay services
   are mapped to dedicated or shared resources in the underlay network
   in a way that meets customer guarantees for service level objectives
   and for separation from other customers' traffic.  [RFC8453] the
   function of ACTN as collecting resources to establish a logically
   dedicated virtual network over one or more TE networks.  Thus, in the
   case of a TE-enabled underlying network, the ACTN VN can be used as a
   basis to realize an IETF network slicing.

   While the ACTN framework is a generic VN framework that can be used
   for VN services beyond the IETF network slice, it also a suitable
   basis for delivering and realizing IETF network slices.

   Further discussion of the applicability of ACTN to IETF network
   slices including a discussion of the relevant YANG models can be
   found in [I-D.king-teas-applicability-actn-slicing].

6.3.  Applicability of Enhanced VPNs to IETF Network Slices

   An enhanced VPN (VPN+) is designed to support the needs of new 
   applications, particularly applications that are associated with 5G
   services, by utilizing an approach that is based on existing VPN an
   d Traffic Engineering (TE) technologies and adds characteristics that
   specific services require over and above traditional VPNs.

   An enhanced VPN can be used to provide enhanced connectivity services
   between customer sites (a concept similar to an IETF Network Slice) 
   and can be used to create the infrastructure to underpin network
   slicing.
   
   It is envisaged that enhanced VPNs will be delivered using a
   combination of existing, modified, and new networking technologies.

   [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced 
   Virtual Private Network (VPN+) services.
   
6.4.  Network Slicing and Slice Aggregates in IP/MPLS Networks

   Network slicing provides the ability to partition a physical network
   into multiple isolated logical networks of varying sizes, structures,
   and functions so that each slice can be dedicated to specific
   services or customers. 
   
   The Differentiated Service (Diffserv) model allows for carrying
   multiple services on top of a single physical network by relying on
   compliant nodes to apply specific forwarding treatments on to packets
   that carry the respective Diffserv code point.  This approach is
   developed in [I-D.bestbar-teas-ns-packet] to realize network slicing
   in IP/MPLS networks.  This solution is agnostic to the path control
   technology used in the network slicing domain and allows service
   differentiation of traffic within a given network slice.
END