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

[Adrian Farrel <[e-mail]>]

Thanks, Jie.

These are helpful suggestions.

Best,
Adrian

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

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
   briefly introduce some existing approaches that can be applied to
   realize IETF Network Slices.

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:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Thursday, April 22, 2021 4:46 AM
> To: 'TEAS WG' <[e-mail]>
> Cc: [e-mail]
> Subject: [Teas] Proposal for text on realising network slices
> 
> 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
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas