Subject: [Teas] Proposal for text on realising network slices

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Apr 2021 21:45:59 +0100

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

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 21 Apr 2021 21:29:15 -0700

Hi Adrian,

FWIW, changes look good to me.
Comments below [Uma]:

Thx!

--
Uma C.

> 6.2.  Applicability of ACTN to IETF Network Slices

[Uma]: I found Figure 4 in the original text  very useful and I presume
that would be
            covered in [I-D.king-teas-applicability-actn-slicing].

>    found in [I-D.king-teas-applicability-actn-slicing].

[Uma]: It would be great if this section reflects what is necessary and
sufficient technologies for realizing the IETF network slicing.
The not-so-nice outcome would be to have someone, who is not fully active
in IETF mailing lists,  in an illusion that these are
*the* technologies to realize on what is laid out w.r.t
underlay capabilities/requirements.
We can go on here, but I would leave it there. Thank you!

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 27 Apr 2021 06:57:03 +0000

Hi Adrian, 

Thanks for your efforts in putting things together and polishing the text. 

Please find some comments on the new section 6:

1. Section 6.1 is more like a summary of the high-level procedures than what its current title "underlying technology" means. Perhaps the title could be updated as:

 "6.1.  Procedures to Realize IETF Network Slices END"

And the last sentence could also be update a little bit:

OLD
   The following sections

NEW
   The following sections
   briefly introduce some existing architectural approaches that can
   be applied to  realize IETF Network Slices.
END

2. Section 6.4 refers to draft-bestbar as existing approach, as mentioned in another mail, that document is an individual draft, and the relationship between slice aggregate and the enhanced VPN work in section 6.3 still need to be clarified. Moreover, it is more related to deep-dive technologies rather than a high-level architecture. Thus the suggestion is to drop 6.4 for now, it may be added later when some further progress in the alignment between the two drafts and the terminologies are made. 

Hope this helps.

Best regards,
Jie

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, April 22, 2021 4:46 AM
> To: 'TEAS WG' <[email-masked]>
> Cc: [email-masked]
> Subject: [Teas] Proposal for text on realising network slices
> 
> All,
> 
> 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.
> 
> 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
>                                                      |    and
> Concepts

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Apr 2021 09:45:28 +0100

Thanks, Jie.

These are helpful suggestions.

Best,
Adrian

-----Original Message-----
From: Dongjie (Jimmy) <[email-masked]> 
Sent: 27 April 2021 07:57
To: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] Proposal for text on realising network slices

Hi Adrian, 

1. Section 6.1 is more like a summary of the high-level procedures than what
its current title "underlying technology" means. Perhaps the title could be
updated as:

OLD
   The following sections

NEW
   The following sections

2. Section 6.4 refers to draft-bestbar as existing approach, as mentioned in
another mail, that document is an individual draft, and the relationship
between slice aggregate and the enhanced VPN work in section 6.3 still need
to be clarified. Moreover, it is more related to deep-dive technologies
rather than a high-level architecture. Thus the suggestion is to drop 6.4
for now, it may be added later when some further progress in the alignment
between the two drafts and the terminologies are made. 

Hope this helps.

Best regards,
Jie

> This is based on my earlier suggestion (on the list) about reducing the
ACTN
> I will leave a respectful period of time and then post an update. Once
updated,